Dimitry -

If you are using ODBC, you can determine the error using AERROR()

lnresult = SQLEXEC(ln,"SELECT * FROM MEMBERS")
IF lnResult = -1
   AERROR(aErr)
ENDIF

Then you can get the specific error message from aErr(5)

See VFP Help for more details on AERROR().

HTH

>Hi Evan,
>
>Thank you for the suggestion. I did think about the same approach, which I will implement. It would be better if there was an error number to each error. That way, "translating" error number to a "friendly" message would be easier. I will have to parse the message and find a string by which to decide what friendly message to display.
>
>
>>Hi Dmitry,
>>
>>You may wish to consider the following approach:
>>
>>A) Wrap your SQL code which performs this operation in a TRY/CATCH block, trapping for the error(s) you care about in the CATCH portion;
>>B) When an error is trapped, send the error code/message to an exception handler which reformats or re-words the message in a more "friendly" fashion and displays it to the user, again in a more "friendly" dialog (you also might want to LOG the error as well...)
>>
>>This allows you to use the SAME message for different connections/location where you're performing this operation, and also maintains consistency in the way you're interfacing with the user when an exception occurs.
>>
>>HTH.
>>
>>>I am looking for suggestions on how to make better reporting of invalid entries back to the UI tier?
>>>
>>>For example, say user enters a duplicate value (where duplicate is not allowed). What I get from the SQL Server as an error message, is the following:
>>>
>>>

>>>Failed updating record in MyTable
>>>Cannot insert duplicate key row in object 'dbo.MyTable' with
>>>unique index 'IX_MyKey'
>>>

>>>
>>>I would like to make the message simpler for the end user to understand.
>>>
>>>Any suggestions would by greatly appreciated.