This article covers the basic of transactions. It describes them and gives examples of committing and rolling back transactions. It also shows how to properly trap errors inside a stored procedure using transactions.
The simplest transaction in SQL Server is a single data modification statement. All my examples use the pubs database. The following
UPDATE authors SET au_fname = 'John' WHERE au_id = '172-32-1176'
is a transaction even though it doesn’t do much. It’s called an Autocommit transaction. SQL Server first writes to the log file what it’s going to do. Then it does the actual update statement and finally it writes to the log that it completed the update statement. The writes to the log file are written directly to disk but the update itself is probably done to a copy of the data that resides in memory. At some future point that database will be written to disk. If the server fails after a transaction has been committed and written to the log, SQL Server will use the transaction log to “roll forward” that transaction when it starts up next.
To make transactions a little more usefull you really need to put two or more statements in them. These are called Explicit Transactions. For example,
BEGIN TRAN UPDATE authors SET au_fname = 'John' WHERE au_id = '172-32-1176' UPDATE authors SET au_fname = 'Marg' WHERE au_id = '213-46-8915' COMMIT TRAN
Note that we have a BEGIN TRAN at the beginning and a COMMIT TRAN at the end. These statements start and complete a transaction. Everything inside these statements is considered a logical unit of work. If the system (Note: change statement to system for clarity) fails after the first update, neither update statement will be applied when SQL Server is restarted. The log file will contain a BEGIN TRAN but no corresponding COMMIT TRAN.
You can also roll back a transaction if it doesn’t do what you want. Consider the following transaction:
BEGIN TRAN UPDATE authors SET au_fname = 'John' WHERE au_id = '172-32-1176' UPDATE authors SET au_fname = 'JohnY' WHERE city = 'Lawrence' IF @@ROWCOUNT = 5 COMMIT TRAN ELSE ROLLBACK TRAN
Suppose that for whatever reason, the second update statement should update exactly five rows. If @@ROWCOUNT, which hold the number of rows affected by each statement, is five then the transaction commits otherwise it rolls back. The ROLLBACK TRAN statement “undoes” all the work since the matching BEGIN TRAN statement. It will not perform either update statement. Note that Query Analyzer will show you messages indicating that rows were updated but you can query the database to verify that no actual data modifications took place.
Hopefully most of your transactions will occur in stored procedures. Let’s look at the second example inside a stored procedure.
Create Proc TranTest1 AS BEGIN TRAN INSERT INTO [authors]([au_id], [au_lname], [au_fname], [phone], [contract]) VALUES ('172-32-1176', 'Gates', 'Bill', '800-BUY-MSFT', 1) UPDATE authors SET au_fname = 'Johnzzz' WHERE au_id = '172-32-1176' COMMIT TRAN GO
The problem with this stored procedure is that transactions don’t care if the statements run correctly or not. They only care if SQL Server failed in the middle. If you run this stored procedure, it will try to insert a duplicate entry into the authors database. You’ll get a primary key violation error message. The message will even tell you the statment has been terminated. But the transaction is still going. The UPDATE statement runs just fine and SQL Server then commits the transaction. The proper way to code this is:
Create Proc TranTest2 AS BEGIN TRAN INSERT INTO [authors]([au_id], [au_lname], [au_fname], [phone], [contract]) VALUES ('172-32-1176', 'Gates', 'Bill', '800-BUY-MSFT', 1) IF @@ERROR <> 0 BEGIN ROLLBACK TRAN return 10 END UPDATE authors SET au_fname = 'Johnzzz' WHERE au_id = '172-32-1176' IF @@ERROR <> 0 BEGIN ROLLBACK TRAN return 11 END COMMIT TRAN GO
You’ll notice that we check each statement for failure. If the statement failed (i.e. @@ERROR <> 0) then we rollback the work performed so far and use the RETURN statement to exit the stored procedure. It’s very important to note that if we don’t check for errors after each statement we may commit a transaction improperly.