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

Now, here things get a bit sticky and versions become important, so hang with me as we go down a very
much winding road. . . .
As I write this, most SQL Server texts for 2008 are not out, but I’ll go ahead and venture the same guess
that I made in the 2005 version of this book — that is, most beginning books will not discuss much in the
way of prior versions. Indeed, I’ve generally avoided discussion of how things were done in prior versions
as it just adds more complexity. That said, I’m going to touch on prior versions in this section. Why?
Well, most database developers will work with code that predates SQL Server 2005 (when TRY/CATCH
was first introduced). Well, there was no formal error handler in SQL Server 2000 and earlier.
With this is mind, I’m going to give you a slimmed-down version of how error handling used to be — if
for no other reason than to help you grasp the “why they did it that way” in older code you may come
across. If you’re certain that you’re going to be a “SQL Server 2005 code or newer only” kinda DBA,
then, by all means, feel free to skip this.
One thing remains common between the old and new error handling models — higher-level runtime errors.
It is possible to generate errors that will cause SQL Server to terminate the script immediately. This was
true prior to TRY/CATCH, and it remains true even in the TRY/CATCH era. Errors that have enough severity
to generate a runtime error are problematic from the SQL Server side of the equation. TRY/CATCH
logic is a bit more flexible for some errors than what we had prior to SQL Server 2005, but we still have
times where our sproc doesn’t even know that something bad happened because the sproc in question
terminated immediately and without notice (at least not to the sproc itself) on the error. On the bright
side, all the current data access object models pass through the message on such errors, so you know
about them in your client application and can do something about them there.
The Way We Were …
In SQL Server 2000 and earlier, there was no formal error handler. You did not have an option that said,
“If any error happens, go run this code over in this other spot.” Instead, we had to monitor for error conditions
within our code and then decide what to do at the point we detected the error (possibly well
after the actual error occurred).
Handling Inline Errors
Inline errors are those pesky little things where SQL Server keeps running as such, but hasn’t, for some
reason, succeeded in doing what you wanted it to do. For example, try to insert a record into the Person
.BusinessEntityContact table that doesn’t have a corresponding record in the BusinessEntity or
Person table:
USE AdventureWorks2008;
GO
INSERT INTO Person.BusinessEntityContact
(BusinessEntityID
,PersonID
,ContactTypeID)
VALUES
(0,0,1);
Chapter 12: Stored Procedures
379