>>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?
>
>If it FK constraint, I don't see why user should be allowed to enter anything that is not in the PK table for the FK.

I guess we are talking about different things. FK constraint can be done on a key that is a unique in a table, not a PK value. For example, an ASSET NUMBER (equipment ID) has to be unique in the table of assets. But it is not a PK value. Yet, on an order form user has to enter this value of asset number. Then the Asset Number should be saved in the Order table. So user can inadvertently make a mistake and enter the wrong value. I understand that I can programatically check if the value is valid by calling the back end and checking if entered value is in the Asset Table. But I thought that it can be check by the constraint just as well (eliminating double pass to SQL Server). And I see now that most people in this thread do not use this approach.