>>It is an error exactly. I can't prevent a user from entering a duplicate value in an ID field. The only way (as far as I know) to trap it is when UPDATE SQL is sent to SQL Server to see what is returned. So I need to inform the user that this entry has been already assigned to another record/row. If you know of a better way to do it, instead of using SQL Server to return an error, please let me know.
>>
>>UPDATE: I meant to say, "it is NOT an error exactly"
>
>Why do you allow user to touch ID instead of generating one?

The ID I refer to is not a PK value. A PK is generated by the application (SQL Server). But the ID is something user needs to have. For example, for every company in a vendor table they have 2 fields Vendor ID and Vendor Name. Vendor ID is up to 10 alphanumeric characters (e.g. "MYCOMP1", "MYCOMP2", etc.). The Name is obviously a name. Their business requires them to have an user-defined ID and obviously it should be unique. This is just one example. There are many other tables (look up tables) that consist of one field, say 15 characters. Those also have to be unique. This is why I need to validate user entry and so far the only way I know is to have SQL Server to accept or reject. In VFP data it was easier because by error number I knew which one was a duplicate entry and I was "translating" a number into a friendly message. In SQL Server case it is more challenging.