Blog Post

Savepoints: The Other Other White Meat

Most T-SQL guides and tutorials I’ve seen concentrate on the following transaction commands: BEGIN, COMMIT, and ROLLBACK, which I’ll henceforth refer to as the “big three”. While they’re certainly very important, there’s also a fourth command, SAVE, which is typically treated like a distant cousin who’s only seen at family reunions every few years. It’s a shame because while SAVE is not always necessary, it can be a huge help when you need it.

If you’ve ever found yourself in a situation where you have a multi-step process that takes a long time to complete, you’re probably using the big three transaction commands to ensure the process is atomic – that everything succeeds or everything fails. Now let’s say that somewhere in the middle of your process one of those steps fails. Your error handling code detects the failure and the transaction is rolled back as if nothing ever happened. This is an acceptable outcome, however all of the time that went into steps of the process that succeeded was for nought. What would really be awesome is a way to rollback only part of a transaction, so all the work that did succeed isn’t lost and your process can attempt to continue. This is exactly where savepoints come in.

What They Do

When you set a savepoint using the SAVE TRANSACTION command, a marker is created within the transaction. Should something go sour later on and you don’t want to rollback the entire transaction, you can rollback just to the savepoint. Everything that occurred before the savepoint will still be there, whereas everything that happened after it will be un-done. Once you rollback to a savepoint, you’ll have the same transactional options you had before: committing the transaction as-is, doing a rollback of the entire transaction, or performing more operations within the transaction and committing (or rolling back) when done.

I should emphasize again that the transaction remains open when rolling back to a savepoint. Savepoints will allow you to get back to a point during a transaction so that you can re-try a failed step (perhaps due to a deadlock or network error) but you still need to complete the transaction by either committing or rolling it all back. If you do a rollback to a savepoint and then forget about it, sooner or later you’ll be trying to figure out why your transaction log has grown so much (and it will be due to an open transaction!)

At this point you may be wondering why you can’t just create a transaction within a transaction and accomplish the same thing by rolling back the inner transaction. You can try, but it won’t work. While it is syntactically possible to create nested transactions, committing a nested transaction does nothing, and rolling one back will not produce the desired effect. I would prove this with a demo, however Paul Randal (blog | twitter) has already done an excellent job of that and I see no sense in duplicating his effort. Check out his blog post if you want to learn more.

How To Use Them

The instructions from Books Online show that the SAVE TRANSACTION command is rather simple. The only argument (which is required) is a name for the savepoint of up to 32 characters in length. You can create multiple savepoints per transaction and can rollback to any of them provided they have different names. If you create a savepoint with a name that’s already in use, the older one will be overwritten and only the newer one will be accessible.

To rollback to a savepoint, specify the savepoint name in the ROLLBACK TRANSACTION statement. Omitting the savepoint name parameter means it’s just a plain old rollback command and the entire transaction will be rolled back just as one would expect. Let’s try it out with some sample code:

-- ** Don't run this all at once!! **
-- You'll want to run these statements one at a time, checking the
--  contents of table 'tbl' in-between each statement!

-- Do this in AdventureWorks (or any other dev db) for safety
USE AdventureWorks2008;

-- create table and add some data
  val VARCHAR(20)
INSERT INTO tbl VALUES (1,'foo');
INSERT INTO tbl VALUES (2,'foofoo');
INSERT INTO tbl VALUES (3,'foobar');
INSERT INTO tbl VALUES (4,'bar');

-- begin our transaction and add another row
INSERT INTO tbl VALUES (5,'fubar');
-- if you select * from tbl, you should now see 5 rows

-- set a savepoint named "Savept"

-- delete a record (oops!)
-- looking at tbl, you'll now see rows 1,2,4,5

-- rollback to the savepoint
-- tbl will now have 5 rows again, just like it did at the savepoint

-- roll it all back
-- tbl will have 4 rows now just like before the transaction

-- clean up our mess :)

Convinced it’s nifty? Awesome! :) One final point I’d like to touch on is locking. Books Online for the SAVE TRANSACTION command emphasizes the fact that locks acquired during a transaction are held until the transaction completes. So what happens when you rollback to a savepoint? Any locks acquired after the savepoint will be released, just like all locks acquired by a transaction are released when the entire transaction is rolled back.

To see this for yourself, run through the above sample code again and open another query window to check the locks held by that process using sp_lock or the sys.dm_tran_locks DMV. You’ll notice that the locks associated with deleting row 3 disappear when rolling back to the savepoint. A notable exception to this behavior is if lock is escalated or converted during the transaction. If that is the case, the lock will not revert to its previous state, and it will not be released until the transaction commits or is rolled back.

So there you have savepoints. They aren’t always necessary, but if you’re really in a pinch they sure can come in handy!

Related Posts

By Bob Pusateri

Bob Pusateri is a Microsoft Data Platform MVP, Microsoft Certified Master of SQL Server, speaker, blogger, volunteer, and author who loves finding new and exciting ways to break and fix things. He works as a consultant and architect, specializing in data, virtualization, and cloud technologies.


  • Deon Lumpkin


    Great savepoint article. I was wondering if once a savepoint tran is rolled back to the originating savepoint, where does it go afterward…

    1) to the COMMIT TRAN
    2) Other?

    I am implementing savepoints in my stored procedure and need the savepoint to go straight to the COMMIT TRAN, then loop back to the next record to be processed.

    Your assistance is greatly appreciated.


    • Bob Pusateri

      Hi Deon,

      Thanks for reading! I’m not sure I understand your question, but I’ll try my best.

      Once a transaction rolls back to a savepoint, you’re in the exact same state you were at when the savepoint occurred. So when you ask “where does it go afterward?” it can go anywhere you want it to. You can perform additional operations, commit it, or roll the entire transaction back.

      It sounds like you have a stored procedure with a loop, and each iteration is a separate transaction. If you’re going to commit the transaction immediately after the savepoint, the savepoint will be of no use. If all the loop iterations are part of a single transaction, I could see a savepoint at the end of each iteration being useful, but it depends on what you’re trying to do. Feel free to email me if you have any more questions. Hope this helps!


Leave a Reply

Your email address will not be published. Required fields are marked *