Naomi,

You're right ... it's not 100% bullet-proof. If you check for a duplicate, but don't save right away, someone else may get in a Save with the same ID ahead of your Save. The likelyhood of that happening totally depends on the type of application you're developing, so you should probably have similar code checking for this in your Save DataAccess method, as Evan suggests.

The reason for doing it the way I mentioned is for immediate feedback to the user that they've entered a duplicate ID. Our error checking routines give our controls a red backcolor for an immediate indication that something's wrong.

I probably should have mentioned that to Dmitry. <g>

~~Bonnie



>Hi Evan,
>
>I was thinking along the same lines as well. Bonnie's approach may not be 100% bullet proof.
>
>>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.