March 13, 2005 at 10:21 pm
Hi all,
I am up to a point on my project where meaningful error messages need to be displayed to the users. Searching about the web has assured me that there is no way to suppress the default errors being raised to the client app (such as err 2627, duplicate key constraint violation). The descriptions of this error will be meaningless to the user so I am after some suggestions of how to trap these SQL Server errors and convert them to some kind of nice english equivilant.
One possibility is to trap the error in the application "catch" statement then use the error number to retrieve from another table the english statement. Not ideal, but do-able.
Any other suggestions?
Thanks,
Steele.
PS. Is there any reason to return my own integer error number from the procedure after inspecting the @@ERROR code. Won't the server error trigger the catch first and my return value be lost??
March 14, 2005 at 9:04 am
One thing you could do is return the output from SQL as XML, then the XML returned to the document can be read and any 'friendly' error messages placed in there.
You can create a table that cross references the SQL error and prepends a comment node to the data returned to the application.
SQL returns:
<root><comment no="1234" val="A really friendlymessage" />
...
SQL output
...
</root>
APP:
string sComment="";
try
{
... declare xml reader, open SQL connection etc.
sComment = xmlReader("no").toString() + xmlReader("val");
... loop round data
}
catch
{
lblError.Text+=sComment;
}
In this way all the business logic remains in the database, as does the table containing the friendly versions of SQL messages meaning it can be reused in other apps.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply