Hi keith,

>Ok, well let's remove Pkeys from the discusssion. That's
>not really what I'm getting at. Let me amened the question
>to whether it is more efficient to check for a duplicate
>value in a CANDIDATE key by trapping for an error
>or doing a seek on any CANDIDATE key(s) before doing an
>add or change.

Trapping the error is required anyways. Using a SEEK is not secure enough. With seek you'll have to seek trough deleted records also, or filter the candidate with FOR !DELETED(). Besides, in a heavy multiusers environment, it is possible that someone else inserted that same key and your workstation didn't get this information yet (You can only be sure to lock the table and then seek for the key) or the other way arround.

With a candidate key you're sure that there cannot be two identical values in the index, not via your program, but not via the command windows or ODBC either. You'll prevent the existance of duplicate keys. With SEEK you're preventing the entering duplicatekeys, not blocking the existance.

I'll vote for trapping the error !!

Walter,