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

Chapter 12: Stored Procedures
Confirming Success or F ailure
with Return Values
You’ll see return values used in a couple of different ways. The first is to actually return data, such as
an identity value or the number of rows that the sproc affected. Consider this an evil practice from the
dark ages. Instead, move on to the way that return values should be used and what they are really there
for — determining the execution status of your sproc.
If it sounds like I have an opinion on how return values should be used, it’s because I most definitely do.
I was actually originally taught to use return values as a “trick” to get around having to use output
parameters — in effect, as a shortcut. Happily, I overcame this training. The problem is that, like
most shortcuts, you’re cutting something out and, in this case, what you’re cutting out is rather
important.
Using return values as a means of returning data back to your calling routine clouds the meaning of the
return code when you need to send back honest-to-goodness error codes. In short — don’t go there!
Return values are all about indicating success or failure of the sproc, and even the extent or nature of
that success or failure. For the C-style programmers among you, this should be a fairly easy strategy to
relate to — it is a common practice to use a function’s return value as a success code, with any non-zero
value indicating some sort of problem. If you stick with the default return codes in SQL Server, you’ll
find that the same rules hold true.
How to Use RETURN
376
Actually, your program will receive a return value whether you supply one or not. By default, SQL
Server automatically returns a value of zero when your procedure is complete.
To pass a return value back from our sproc to the calling code, we simply use the RETURN statement:
RETURN []
Note that the return value must be an integer.
Perhaps the biggest thing to understand about the RETURN statement is that it unconditionally exits from
your sproc. That is, no matter where you are in your sproc, not one single more line of code will execute
after you have issued a RETURN statement.
By unconditionally, I don’t mean that a RETURN statement is executed regardless of where it is in code.
On the contrary, you can have many RETURN statements in your sproc, and they will only be executed
when the normal conditional structure of your code issues the command. Once that happens, however,
there is no turning back.
Let’s illustrate this idea of how a RETURN statement affects things by writing a very simple test sproc:
USE AdventureWorks2008;
GO