Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

catastrophic (20–25). If you raise an error of severity 19 or higher (system level), the WITH LOG option
must also be specified; 20 and higher automatically terminates the users’ connections. (Kind of fun if
you’re feeling particularly ornery, but they hate that!)
So, let’s get back to what I meant by bizarre. SQL Server actually varies its behavior into more ranges than
Windows does, or even than the Books Online will tell you about. Errors fall into six major groupings:
State
State is an ad hoc value. It’s something that recognizes that exactly the same error may occur at multiple
places within your code. The notion is that this gives you an opportunity to send something of a place
marker for where exactly the error occurred.
State values can be between 1 and 127. If you are troubleshooting an error with Microsoft tech support,
they apparently have some arcane knowledge that hasn’t been shared with you about what some of
these mean. I’m told that if you make a tech-support call to Microsoft, they are likely to ask about and
make use of this state information.
Error Arguments
Chapter 12: Stored Procedures
1–10 Purely informational, but will return the specific error code in the message information
11–16 If you do not have a TRY/CATCH block set up, then these terminate execution of the procedure
and raise an error at the client. The state is shown to be whatever value you set it
to. If you have a TRY/CATCH block defined, then that handler will be called rather than
raising an error at the client.
17 Usually, only SQL Server should use this severity. Basically, it indicates that SQL Server
has run out of resources — for example, tempdb was full — and can’t complete the
request. Again, a TRY/CATCH block will get this before the client does.
18–19 Both of these are severe errors and imply that the underlying cause requires system
administrator attention. With 19, the WITH LOG option is required, and the event will
show up in the Windows Event Log. These are the final levels at which you can trap the
error with a TRY/CATCH block — after this, it will go straight to the client.
20–25 Your world has just caved in, as has the user’s connection. Essentially, this is a fatal
error. The connection is terminated. As with 19, you must use the WITH LOG option and
a message will, if applicable, show up in the Event Log.
Some predefined errors accept arguments. These allow you to make the error somewhat more dynamic
by changing to the specific nature of the error. You can also format your error messages to accept
arguments.
When you want to use dynamic information in what is otherwise a static error message, you need to format
the fixed portion of your message so that it leaves room for the parameterized section of the message.
You do so by using placeholders. If you’re coming from the C or C++ world, then you’ll recognize
the parameter placeholders immediately; they are similar to the printf command arguments. If you’re
391