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

Chapter 12: Stored Procedures
It worked just fine. But if we try to do this using inline error checking, we have a problem:
CREATE TABLE OurIFTest(
Col1 int PRIMARY KEY
);
IF @@ERROR != 0
PRINT ‘Problems!’;
ELSE
PRINT ‘Everything went OK!’;
Run this (you’ll need to run it twice to generate the error if the table isn’t already there) and we quickly
find out that, without the TRY block, SQL Server aborts the script entirely on the particular error we’re
generating here:
Msg 2714, Level 16, State 6, Line 2
There is already an object named ‘OurIFTest’ in the database.
Notice that our PRINT statements never got a chance to execute — SQL Server had already terminated
processing. With TRY/CATCH we were able to trap and handle this error, but using inline error checking,
our attempts to trap an error like this fail.
Handling Errors Before They Happen
384
Sometimes you have errors that SQL Server doesn’t really have an effective way to even know about, let
alone tell you about. Other times we want to prevent the errors before they happen. These we need to
check for and handle ourselves.
To try this out, let’s make a new version of an existing sproc in AdventureWorks2008 called HumanResources
.uspUpdateEmployeeHireInfo — we’ll call ours HumanResources.uspUpdateEmployeeHireInfo2.
In this, let’s address some business rules that are logical in nature, but not necessarily implemented in
the database (or, in this case, even possible to handle with constraints). Let’s start by taking a look at the
existing sproc:
CREATE PROCEDURE HumanResources.uspUpdateEmployeeHireInfo2
@BusinessEntityID int,
@JobTitle nvarchar(50),
@HireDate datetime,
@RateChangeDate datetime,
@Rate money,
@PayFrequency tinyint,
@CurrentFlag dbo.Flag
WITH EXECUTE AS CALLER
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRY
BEGIN TRANSACTION;
UPDATE HumanResources.Employee
SET JobTitle = @JobTitle,