>No, I think this doesn´t quite solve the problem. I should define the >surrogate key as PRIMARY and my original key as CANDIDATE, and the problem >would keep popping up. (Defining the original key as REGULAR just ignores >the problem.) it solved the problem in the sense that each record that is added has a unique key you have to check for duplicate "data" keys in the insert trigger etc. > >I'm not sure about this either; in the many-to-many link I would need to >use, instead of KEY_A+KEY_B, SURROGATE_A+SURROGATE_B; the problem with >compound indexes would remain. Anyway, you would need to define KEY_A+KEY_B >as CANDIDATE, and the original problem is still with us. no as you would add a 3rd surrogate key for the N-N connection table and have the other keys as foreign keys in this table.. >I have been showing my example code to many FoxPro programmers, and they >all called it a serious problem. When I worked with old fashioned things >like COBOL, if I deleted a primary key, it stayed deleted! (It didn't´t show >up in READs, it caused no problems in WRITEs, and so on.) this is what you pay for having the option to RECALL deleted records btw you can also recycle Deleted keys (i.e. re-use the deleted record) Arnon