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

ELSE -- hmm, we don’t recognize it, so report it and bail
RAISERROR(‘something not good happened this time around’, 16, 1 );
END CATCH
If you run this in a database that does not already have the OurIFTest table, then you will get a simple:
Command(s) completed successfully.
But run it where the OurIFTest table already exists (for example, run it twice if you haven’t run the
CREATE code before) and you get something to indicate the error:
WARNING: Skipping CREATE as table already exists
A error was logged. The Log ID for our error was 3
Note that the actual error number you see will depend on whether the ErrorLog table has already had
other errors inserted in it before you ran this test.
Now run a little select against the error log table:
SELECT *
FROM ErrorLog
WHERE ErrorLogID = 3; -- change this value to whatever your
-- results said it was logged as
And you can see that the error was indeed properly logged:
ErrorLogID UserName ErrorMessage
----------- ----------- ---------------------------------------------------
3 dbo There is already an object named ‘OurIFTest’ ...
(1 row(s) affected)
Chapter 12: Stored Procedures
There are several things that you should take note of between the sproc itself and the usage of it by the
calling script:
❑ The OUTPUT keyword was required for the output parameter in the sproc declaration.
❑ You must use the OUTPUT keyword when you call the sproc, much as you did when you
declared the sproc. This gives SQL Server advance warning about the special handling that
parameter will require. Be aware, however, that forgetting to include the OUTPUT keyword won’t
create a runtime error (you won’t get any messages about it), but the value for the output parameter
won’t be moved into your variable (you’ll just wind up with what was already there —
most likely a NULL value). This means that you’ll have what I consider to be the most dreaded
of all computer terms — unpredictable results.
❑ The variable you assign the output result to does not have to have the same name as the internal
parameter in the sproc. For example, in our previous sproc, the internal parameter in the error
logging sproc was called @ErrorLogID, but the variable the value was passed to was called
@MyOutputParameter.
❑ The EXEC (or EXECUTE) keyword was required since the call to the sproc wasn’t the first thing in
the batch (you can leave off the EXEC if the sproc call is the first thing in a batch) — personally, I
recommend that you train yourself to use it regardless.
375