John

>Personally, I'm not in love with candidate keys. I generally have a non-data bearing primary key using a GUID or something guaranteed to be unique and make everything else regular. If I need to trap uniqueness, I so a SEEK before saving. There is a difference between enforcing uniqueness in business logic and enforcing uniqueness via domain using candidates. The difference is, if you enforce it with candidate keys, you will get errors that you have to trap via an error handler. Simpler to avoid them via business logic.

IMO enforcing them at the bisuness logic is not simpler than trapping the error (When using TABLEUPDATE(2, .., ..) an error is not even generated), Especially when in a highly multiuser environment where buffering is used at both the VFP and OS level, different NOSs where updates are not imidiately transmitted to other workstations, a discovered bug in the SEEK() function, etc. Fact is that no matter how secure your business logic is, there always will be possibilities to insert duplicate keys into the table (Do not confuse keys with indexes). When using candidate indexes you're absolutely sure that no two same keys exists, not matter how and when the table was accessed (ODBC, VFP IDE, Businesrules, etc).

One question though. How would you solve the problem *IF* you upsized to SQL ? I'll bet 10 to 1 that most developers would use candidate keys.....

Walter,