>>>What is the most efficient way of handling this?
>>>Assuming I have a compound PKEY or CANDIDATE
>>>should I do a SEEK before modifying a one of
>>>the components or is it more efficient to trap
>>>for the error?
>>>
>>>   ...kt
>>
>>Really IMHO the proper way to do this is to generate the primary key yourself, and make sure its unique when generated. This means either use a table to keep track of keys generated for each table, or come up with a key routine that will always give you a unique value, something along the lines of SYS(0)+SYS(2015) which should pretty much guarantee a unique value.
>
>That's a lot of people's HO :-)
>
>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.

Ahh, different question. I would recomend checking rather than trapping an error. Use the table again or use a parameterized view to look for the key already existing. Now, you must know if its an already existing record or not as well.