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

HireDate = @HireDate,
CurrentFlag = @CurrentFlag
WHERE BusinessEntityID = @BusinessEntityID;
INSERT INTO HumanResources.EmployeePayHistory
(BusinessEntityID,
RateChangeDate,
Rate,
PayFrequency)
VALUES (@BusinessEntityID, @RateChangeDate, @Rate, @PayFrequency);
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
-- Rollback any active or uncommittable transactions before
-- inserting information in the ErrorLog
IF @@TRANCOUNT > 0
BEGIN
ROLLBACK TRANSACTION;
END
EXECUTE dbo.uspLogError;
END CATCH;
END;
What’s going on in this sproc is pretty straightforward: There are two statements (one to update the
existing employee record and one to handle the additional history record) plus a very generic error handler.
What we’re going to do is add some new code to this sproc to recognize some errors that might
occur and provide return values that will notify the client of more specific error information. We’re not
going to take the time to trap every potential error here, but we will catch some basics just to show how
things might work. (Feel free to explore further on your own.)
The error handler in this sproc is very generic and doesn’t really do anything that is specific to this particular
sproc, so let’s start by considering some of the errors that might occur in this sproc, for example:
❑ An Employee Whose BusinessEntityID doesn’t already exist: The UPDATE statement in the
sproc will actually run just fine (no errors) without a valid BusinessEntityID. It will just fail to
find a match and wind up affecting zero rows; the error here is logical in nature, and SQL Server
will see no problem with it at all. We should detect the error ourselves and trap it at this point
before the sproc continues (since there is a foreign key between EmployeePayHistory and
Employee, SQL Server will wind up raising an error on the INSERT statement when it can’t find
a matching BusinessEntityID).
❑ Two updates affecting the same BusinessEntityID at the same RateChangeDate: Again, the
UPDATE statement will have no issues with such an update, but the INSERT statement will (the
primary key for EmployeePayHistory is the composite of BusinessEntityID and RateChangeDate).
Let’s address each of these in a new version of the sproc.
Chapter 12: Stored Procedures
First, let’s lay some groundwork. While SQL Server doesn’t really have the concept of a constant, I’m
going to use some variables as though they are constants. By doing so, I’m going to get away from just
385