Question

I put transactions in all my “set” procedures. No problems. Everything works.

In this case, I need one set procedure, to call another, thankfully, only once, or that would potentially complicate things further.

So the happy bath would be.

• I’m in ProcA and start a transaction.
• It calls ProcB and it starts a transaction.
• ProcB is successful and commits.
• ProcA is successful and commits.

However, what happens if ProcB fails, rollsback, and rethrows the error. It should cause ProcA to rollback as well correct?

What if ProcB succeeds, commits, then ProcA subsequently fails, and rollsback…will what happened in ProcB be rolled back? or is it commited?

I need these two to work together, either both succeed, or fail and both be rolled back. What’s the best way to ensure this happens?

I’m working with Microsoft SQL Server 2008 R2 (SP1)

Note: If ProcB requires a transaction because it can be called without ProcA wrapping it. And technically, ProcA won’t always call ProcB (depends on input).

Answer 1

Here’s a simple demo to show what happens with nested transations:

CREATE TABLE TranTest (Field1 INTEGER)

BEGIN TRANSACTION
SELECT @@TRANCOUNT -- 1 open transaction
INSERT TranTest VALUES (1)

    BEGIN TRANSACTION
    SELECT @@TRANCOUNT -- 2 open transactions
    INSERT TranTest VALUES (2)
    ROLLBACK TRANSACTION -- this rolls back ALL transaction

SELECT @@TRANCOUNT -- 0 open transactions (you may have expected 1?)
SELECT * FROM TranTest -- No rows

Instead f the ROLLBACK above, if you did a COMMIT TRANSACTION, this actual does nothing other then decrement @@TRANCOUNT. So you then would need to to either COMMIT the outer transaction (which would COMMIT both rows to the table), or do a ROLLBACK which would result in no rows being committed to the table.

Here’s the MSDN ref on nested transactions: http://msdn.microsoft.com/en-us/library/ms189336.aspx