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

Note the removal of the HireDate column from the UPDATE.
As we discussed earlier, the RETURN will immediately exit the sproc supplying the return value provided
(in this case, –1000 — the amount matching our variable). Our client application can now test the return
value and match it against a known list of possible errors.
That moves us on to our second potential error. We have a couple of ways we can handle this. We could
pre-query the EmployeePayHistory table to see if it already has a matching row, and then avoid the
INSERT entirely. Alternatively, we can just allow SQL Server to detect the error and just beef up the error
handler to address that known possibility. In this case, I’m going to opt for the latter. It is almost always
better to treat the rule and handle the exception. We would like to think that this particular error is going
to be very infrequent, so we’ll largely assume it isn’t going to happen and address it when it does. With
this in mind, we only need to make some alterations to our error handler:
…
…
BEGIN CATCH
-- Rollback any active or uncommittable transactions before
-- inserting information in the ErrorLog
IF @@TRANCOUNT > 0
BEGIN
ROLLBACK TRANSACTION;
END
EXECUTE dbo.uspLogError;
IF ERROR_NUMBER() = 2627 -- Primary Key violation
BEGIN
PRINT ‘Duplicate Rate Change Found’;
RETURN @DUPLICATE_RATE_CHANGE;
END
END CATCH;
…
…
Chapter 12: Stored Procedures
OK, so with all these changes in place, let’s take a look at our new overall sproc. While this is a new
sproc, I’m highlighting only those lines that change versus the original we cloned it from:
CREATE PROCEDURE HumanResources.uspEmployeeHireInfo2
@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;
387