>>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?
>
>Because of all the possibilities of optimistic buffering and other users editing the same record, changing data that make up unique keys, you are better off trapping the error.

Unlike most environments here, mine is primarily a
batch oriented one. My primary focus here is
trying to determine whether it is more efficient
to allow the error to occur and deal with that,
or ensure that an error won't occur in the first
place.

> The best way is to have a surrogate integer PK field that can not be modified [or even be seen] by the user. Then use a PK generator to populate all your PK fields. Then use Candidate keys for user editable data and error trap those duplicates.

I've seen pros & cons to this approach many times
before. Even with it though, you're still going
to encounter the same issue with the CANDIDATE
key. This issue is that the key will allow no
duplicates.

   ...kt