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

Chapter 12: Stored Procedures
Note that this wasn’t a SQL Server error — as far as SQL Server’s concerned, everything about life is just
fine. What’s nice, though, is that, were we using a client program (say one you wrote in C#, VB.NET, C++,
or some other language), we would, as with our duplicate insert pay history item, be able to track the
–1000 against a known constant and send a very specific message to the end user.
Manually Raising Errors
Sometimes you have errors that SQL Server doesn’t really know about, but you wish it did. For example,
perhaps in the previous example you don’t want to return –1000. Instead, you’d like to be able to create
a runtime error at the client end that the client would then use to invoke an error handler and act accordingly.
To do this, you use the RAISERROR command in T-SQL. The syntax is pretty straightforward:
RAISERROR (, ,
[,
[,]] )
[WITH option[,...n]]
Let’s take a look at what these mean.
Message ID/Message String
The message ID or message string you provide determines which message is sent to the client.
Using a message ID creates a manually raised error with the ID that you specified and the message that
is associated with that ID as found in the sys.messages system view in the master database.
If you want to see what your SQL Server has as predefined messages, you can always perform a
SELECT * FROM master.sys.messages. This includes any messages you’ve manually added to
your system using the sp_addmessage stored procedure or through the SQL Server Management
Studio.
You can also just supply a message string in the form of ad hoc text without creating a more permanent
message in the system:
RAISERROR (‘Hi there, I’’m an error’, 1, 1);
This raises a rather simple error message:
Hi there, I'm an error
Msg 50000, Level 1, State 1
Notice that the assigned message number, even though you didn’t supply one, is 50000. This is the
default error value for any ad hoc error. It can be overridden using the WITH SETERROR option.
Severity
390
We got a quick overview of this when looking at TRY/CATCH in the chapter on scripting. For those of you
already familiar with Windows servers, severity should be an old friend. Severity is an indication of just
how bad things really are based on this error. For SQL Server, however, what severity codes mean can
get a little bizarre. They can range from informational (severities 1–18), to system level (19–25), and even