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

CREATE PROC spTestReturns
AS
DECLARE @MyMessage varchar(50);
DECLARE @MyOtherMessage varchar(50);
SELECT @MyMessage = ‘Hi, it’’s that line before the RETURN’;
PRINT @MyMessage;
RETURN;
SELECT @MyOtherMessage = ‘Sorry, but we won’’t get this far’;
PRINT @MyOtherMessage;
RETURN;
Note that I didn't choose to initialize the two message variables in the declaration this time. Why? Well,
in this case, I believe it makes for substantiallly more readable code if I keep the initialization on it's own
line — this is going to be true with most any string variable where the initial value is more than a few
characters long.
OK, now we have a sproc, but we need a small script to test out a couple of things for us. What we want
to see is:
❑ What gets printed out
❑ What value the RETURN statement returns
To capture the value of a RETURN statement, we need to assign it to a variable during our EXEC statement.
For example, the following code would assign whatever the return value is to @ReturnVal:
EXEC @ReturnVal = spMySproc;
Now let’s put this into a more useful script to test out our sproc:
DECLARE @Return int;
EXEC @Return = spTestReturns;
SELECT @Return;
Short but sweet — when we run it, we see that the RETURN statement did indeed terminate the code
before anything else could run:
Hi, it’s that line before the RETURN
-----------
0
(1 row(s) affected)
Chapter 12: Stored Procedures
We also got back the return value for our sproc, which was zero. Notice that the value was zero even
though we didn’t specify a specific return value. That’s because the default is always zero.
Think about this for a minute — if the return value is zero by default, then that means that the default
return is also, in effect, “No Errors.” This has some serious dangers to it. The key point here is to make
sure that you always explicitly define your return values — that way, you are reasonably certain to be
returning the value you intended, rather than something by accident.
377