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.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham