>>>I do want constraint but I want the message to the user to be simple and practical. So I guess what I am getting from this discussion is that I will need to "translate" the technical message from SQL Server into a more user-friendly one. I think I will use the name of the constraint as a key for "translation."
>>
>>It doesn't make any sense. Why would you allow from end to accept invalid data in the first place?
>
>This is the question. Should I call the SQL table to check if user made a valid entry (by querying the primary table UNIQUE field) or rely on the constraint to catch the invalid entry. In the VFP back end I am using the index and SEEK for the value before writing update. I thought that to minimize the trips to SQL Server to simply make the data go only one time and rely on the constraint. The point is that SQL Server will check for the constraint anyway, why not rely on it for data validation?

Dmitry,
I agree with what Naomi and other said about pre-checking for the value. If you try to parse a sql failure you have introduced two additional problems. One is performance as a SQL failure depending on your DA code will most likely be slower than your pre-testing. Second you have control over the outcome. What I mean by that is if you try to determine the failure based on a SQL server return message of some kind and the next version of SQL changes that slightly you will be without a paddle. If you just test for the value and if not exist give the user a message. That is better timing anyway as you can check it when appropriate before a save is tried.
Just my .02
Tim