Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
aiken
Aged Yak Warrior
525 Posts |
Posted - 2003-02-01 : 01:17:13
|
I believe that I'm doing the right thing by trying to move out of the old world of returning a status code in stored procedures, either via SELECT or by an output variable, and into proper error handling by raising errors using RAISERROR.First, can anyone comment on whether I'm correct in thinking that that's a step forward? I was thinking of defining a specific severity and using custom error messages so my ASP app could notify the user of what the DB error was without having to do a lot of processing in the ASP pages.Second, can anyone point to code samples or give advice for handling the DB errors, using either ADODB.RecordSet.Open or ADODB.Command.Execute? Right now, when I throw an error in the DB, it kills processing of the ASP page. Should I be using On Error Resume Next and then testing something? Or am I completely off base?Thanks-Brooks |
|
mohdowais
Sheikh of Yak Knowledge
1456 Posts |
Posted - 2003-02-01 : 01:47:10
|
Hi BrooksPoor error-handling is one of the major limitations of using a scripting language, particularly VBScript. I am afraid much of the time you are restricted to using "On Error Resume Next" at the top of the page, and then checking for errors after every DB statement. Of course, you cant depend upon the Err object for all the errors emnating from the DB, for this purpose its generally a good idea to query the ADODB.Connection.Errors collection. This advantage here is that returns (or at least is expected to ) as many errors or information messages sent by the database during execution. Btw, the error-handling in .NET is much much better with Try, Catch & Finally blocks, and the Errors collection in the ADO.NET connection object actually CONTAINS all the error messages. One technique that we've used with classic ASP for sometime is to populate a table variable inside the SP with all error/informational messages raised in the SP with their severity levels, and then SELECT to return a recordset of the messages (we had to do this since we had more information messages than critical errors). We could not depend upon the ASPError Object or Connection.Errors collection to give us all the messages. I dont know if this was the best way to do it, maybe somebody can guide me too OS |
|
|
|
|
|
|
|