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

SELECT @Error = @@ERROR;
-- Print out a blank separator line
PRINT ‘’;
-- The value of our holding variable is just what we would expect
PRINT ‘The Value of @Error is ‘ + CONVERT(varchar, @Error);
-- The value of @@ERROR has been reset - it’s back to zero
-- since our last statement (the PRINT) didn’t have an error.
PRINT ‘The Value of @@ERROR is ‘ + CONVERT(varchar, @@ERROR);
Now execute your script and you can examine how @@ERROR is affected:
Msg 547, Level 16, State 0, Line 4
The INSERT statement conflicted with the FOREIGN KEY constraint
“FK_BusinessEntityContact_Person_PersonID”. The conflict occurred in database
“AdventureWorks2008”, table “Person.Person”, column ‘BusinessEntityID’.
The statement has been terminated.
The Value of @Error is 547
The Value of @@ERROR is 0
This illustrates pretty quickly the issue of saving the value from @@ERROR. The first error statement is
only informational in nature. SQL Server has thrown that error, but hasn’t stopped the code from executing.
Indeed, the only part of that message that your sproc has access to is the error number. That error
number resides in @@ERROR for just that next T-SQL statement; after that, it’s gone.
Using @@ERROR in a Sproc
Chapter 12: Stored Procedures
Notice that @Error and @@ERROR are two separate and distinct variables and can be
referred to separately. This isn’t just because of the case difference. (Depending on
how you have your server configured, case sensitivity can affect your variable names.)
It’s because of the difference in scope. The @ or @@ is part of the name, so the number
of @ symbols on the front makes each one separate and distinct from the other.
OK, so let’s start with an assumption here: If you’re using @@ERROR, then the likelihood is that you are
not using TRY/CATCH blocks. If you have not made this choice for backward compatibility reasons, I’m
going to bop you upside the head and suggest you reconsider — TRY/CATCH is the much cleaner and allaround
better way.
TRY/CATCH will handle varieties of errors that in previous versions would have ended your script
execution.
That said, TRY/CATCH is out of the equation if backward compatibility with SQL Server 2000 or prior is
what you need, so let’s take a quick look.
What we’re going to do is look at two short procedures. Both are based on things we have already done
in scripting or in earlier stored-procedure examples, but we want to take a look at how inline error
381