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

Chapter 14: Transactions and Locks
indeed be set to –25, even though it logically appeared that we prevented this through the use of our IF
statement.
We can prevent this problem in only two ways:
❑ Create a CHECK constraint and monitor for the 547 Error.
❑ Set our isolation level to be REPEATABLE READ or SERIALIZABLE.
The CHECK constraint seems fairly obvious. The thing to realize here is that you are taking something of
a reactive rather than a proactive approach with this method. Nonetheless, in most situations we have a
potential for non-repeatable reads, so this would be my preferred choice in most circumstances.
We’ll be taking a full look at isolation levels shortly, but for now, suffice it to say that there’s a good chance
that setting it to REPEATABLE READ or SERIALIZABLE is going to cause you as many headaches as it
solves (or more). Still, it’s an option.
Phantoms
436
No, we’re not talking the of the Opera kind here — what we’re talking about are records that appear mysteriously,
as if unaffected by an UPDATE or DELETE statement that you’ve issued. This can happen quite
legitimately in the normal course of operating your system and doesn’t require any kind of elaborate
scenario to illustrate. Here’s a classic example of how this happens.
Let’s say you are running a fast food restaurant. If you’re running a typical establishment of that kind,
you probably have a fair number of employees working at the minimum wage as defined by the government.
The government has just decided to raise the minimum wage from $6.50 to $7.50 per hour, and you
want to run an UPDATE on the EmployeePayHistory table to move anyone making less than $7.50 per
hour up to the new minimum wage. “No problem,” you say, and you issue the rather simple statement:
UPDATE HumanResources.EmployeePayHistory
SET HourlyRate = 7.50
WHERE HourlyRate < 7.50;
ALTER TABLE Employees
ADD ckWage CHECK (HourlyRate >= CONSTRAINT 7.50);
GO
That was a breeze, right? Wrong! Just for illustration, we’re going to say that you get an error message back:
Msg 547, Level 16, State 1, Line 1
ALTER TABLE statement conflicted with COLUMN CHECK constraint ‘ckWage’. The
conflict occurred in database ‘AdventureWorks2008’, table ‘EmployeePayHistory’,
column ‘Rate’.
So you run a quick SELECT statement checking for values below $7.50, and sure enough you find one.
The question is likely to come rather quickly, “How did that get there? I just did the UPDATE that should
have fixed that!” You did run the statement, and it ran just fine — you just got a phantom.
The instances of phantom reads are rare and require just the right circumstances to happen. In short,
someone performed an INSERT statement at the very same time your UPDATE was running. Since it was
an entirely new row, it didn’t have a lock on it and it proceeded just fine.