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

Chapter 14: Transactions and Locks
Behind the scenes, something like this is happening:
UPDATE checking
SET Balance = Balance - 1000
WHERE Account = ‘Sally’
UPDATE savings
SET Balance = Balance + 1000
WHERE Account = ‘Sally’
This is a hyper-simplification of what’s going on, but it captures the main thrust of things: You need to
issue two different statements — one for each account.
Now what if the first statement executes and the second one doesn’t? Sally would be out a thousand dollars!
That might, for a short time, seem OK from your perspective (heck, you just made a thousand
bucks!), but not for long. By that afternoon you’d have a steady stream of customers leaving your
bank — it’s hard to stay in the bank business with no depositors.
What you need is a way to be certain that if the first statement executes, the second statement executes.
There really isn’t a way that we can be certain of that — all sorts of things can go wrong, from hardware
failures to simple things, such as violations of data integrity rules. Fortunately, however, there is a way
to do something that serves the same overall purpose — we can essentially forget that the first statement
ever happened. We can enforce at least the notion that if one thing didn’t happen, then nothing did — at
least within the scope of our transaction.
In order to capture this notion of a transaction, however, we need to be able to define very definite
boundaries. A transaction has to have very definitive beginning and end points. Actually, every SELECT,
INSERT, UPDATE, and DELETE statement you issue in SQL Server is part of an implicit transaction. Even
if you issue only one statement, that one statement is considered to be a transaction — everything about
the statement will be executed, or none of it will. Indeed, by default, that is the length of a transaction —
one statement.
But what if we need to have more than one statement be all or nothing, as in our preceding bank example?
In such a case, we need a way of marking the beginning and end of a transaction, as well as the success
or failure of that transaction. To that end, there are several T-SQL statements that we can use to mark
these points in a transaction. We can:
❑ BEGIN a transaction: Set the starting point.
❑ COMMIT a transaction: Make the transaction a permanent, irreversible part of the database.
❑ ROLLBACK a transaction: Say essentially that we want to forget that it ever happened.
❑ SAVE a transaction: Establish a specific marker to allow us to do only a partial rollback.
Let’s look over all of these individually before we put them together into our first transaction.
BEGIN TRAN
428
The beginning of the transaction is probably one of the easiest concepts to understand in the transaction
process. Its sole purpose in life is to denote the point that is the beginning of a unit. If, for some reason,