By David

2010-01-15 18:04:33 8 Comments

I'm interested in the side effects and potential problems of the following pattern:

        [...Perform work, call nested procedures...]
        RAISERROR [rethrow caught error using @ErrorNumber, @ErrorMessage, etc]

To the best of my understanding this pattern is sound when used with a single procedure - the procedure will either complete all of its statements without error, or it will rollback all actions and report the error.

However when one stored procedure calls another stored procedure to do some sub-unit of work (with the understanding that the smaller procedure is sometimes called on its own) I see an issue coming about with relation to rollbacks - an informational message (Level 16) is issued stating The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.. This I assume is because the rollback in the sub-procedure is always rolling back the outer-most transaction, not just the transaction started in the sub-procedure.

I do want the whole thing rolled back and aborted if any error occurs (and the error reported to the client as an SQL error), I'm just not sure of all the side effects that come from the outer layers trying to rollback a transaction that has already been rolled back. Perhaps a check of @@TRANCOUNT before doing a rollback at each TRY CATCH layer?

Finally there is the client end (Linq2SQL), which has it's own transaction layer:

    var context = new MyDataContext();
    using (var transaction = new TransactionScope())
            // Some Linq stuff
    // An error occured!

In the event that a stored procedure, "MySubProcedure", called inside MyStoredProcedure raises an error, can I be sure that everything previously done in MyStoredProcedure will be rolled back, all the Linq operations made by SubmitChanges will be rolled back, and finally that the error will be logged? Or what do I need to change in my pattern to ensure the whole operation is atomic, while still allowing the child parts to be used individually (i.e. the sub-procedures should still have the same atomic protection)


@gbn 2010-01-15 19:18:57

This is our template (error logging removed)

This is designed to handle


  • all TXN begin and commit/rollbacks must be paired so that @@TRANCOUNT is the same on entry and exit

  • mismatches of @@TRANCOUNT cause error 266 because

    • BEGIN TRAN increments @@TRANCOUNT

    • COMMIT decrements @@TRANCOUNT

    • ROLLBACK returns @@TRANCOUNT to zero

  • You can not decrement @@TRANCOUNT for the current scope
    This is what you'd think is the "inner transaction"

  • SET XACT_ABORT ON suppresses error 266 caused by mismatched @@TRANCOUNT
    And also deals with issues like this "SQL Server Transaction Timeout" on

  • This allows for client side TXNs (like LINQ) A single stored procedure may be part of distributed or XA transaction, or simply one initiated in client code (say .net TransactionScope)


  • Each stored proc must conform to the same template


  • So don't create more TXNs than you need

The code


DECLARE @starttrancount int

    SELECT @starttrancount = @@TRANCOUNT

    IF @starttrancount = 0

       [...Perform work, call nested procedures...]

    IF @starttrancount = 0 
    IF XACT_STATE() <> 0 AND @starttrancount = 0 
    --before SQL Server 2012 use 
    --RAISERROR [rethrow caught error using @ErrorNumber, @ErrorMessage, etc]


  • The rollback check is actually redundant because of SET XACT_ABORT ON. However, it makes me feel better, looks odd without, and allows for situations where you don't want it on

  • Remus Rusanu has a similar shell that uses save points. I prefer an atomic DB call and don't use partial updates like their article

@Carl R 2011-07-21 20:29:45

SET NOCOUNT ON doesn't seem necessary?

@Aaron Bertrand 2011-07-21 21:42:02

You should always use SET NOCOUNT ON imho.

@gbn 2011-07-22 06:25:10

@Carl R: SET NOCOUNT ON is pretty much essential in code and triggers: so much client code breaks without it. Also, there it's possible to measure the time taken to process the "xx rows affected messages". See (my question) please

@Carl R 2011-07-22 06:59:55

I thought the @@ROWCOUNT wasn't updated with it on, but I was wrong. Thanks!

@Carl R 2011-07-22 07:10:51

Ah! I've been using RecordsAffected a lot in a previous project. Had completely forgot about that.

@gbn 2011-07-22 07:45:04

@Carl R: RecordsAffected would nbe Ok for a direct INSERT or UPDATE. Via a stored proc (or if there is a trigger, then this most likely be lost eg the INSERT into some audit table. Hence the breaks without using SET NOCOUNT ON

@A-K 2012-02-08 19:09:46

@gbn this pattern makes error handling on the client more difficult. Instead of catching SqlException, and switching on error number of the original exception, I am not getting the original error number. All I can do is parse the text, which is prone to errors.

@gbn 2012-02-08 19:28:31

Yes, one downside. Denali fixes this with Throw. But until then you'd always lose the original error anyway in the catch block, with the trade off for predictabilty of error handlin

@Eric J. 2013-09-30 22:42:53

Do I understand that this provides behavior different than Remus'? My understanding is that his will allow the outer transaction to complete even if the inner transaction fails (thus SAVE TRANSACTION), whereas this will roll back the entire operation if any nested procedure rolls back. Is that understanding correct?

@gbn 2013-10-01 03:54:45

@EricJ. Correct. I roll it all back

@Niraj 2014-05-21 13:39:57

We don’t need transaction for inner stored procs. If we are using transaction in outer most stored procedure it will take care of all inner stored procedures, any error occured in inner stored procedures will be passed to outermost stored procedure and will casue a rollback.So we dont need nested transactions at all.

@gbn 2014-05-21 13:45:55

@Niraj: Correct, but then you get error 266 unless you have SET XACT_ABORT ON.

@Niraj 2014-05-22 12:15:13

@gbn: I wouldn't, cause I am not using transactions in inner stored procs I am using transaction at only one place in the outer most stored procedure only. I raise error from inner stored procedure and catch them in outer transaction and I don't get an error on rollback.

@gbn 2014-05-22 14:01:24

@Niraj: what if you decide to nest stored procedures deeper, or want to call the inner one directly. You are making assumptions. You can still get error 266 if the inner @@TRANCOUNT goes to zero by, say, a batch-aborting trigger error (if you don't have TRY/CATCH). What works for you in a controlled environment is not* the general case that works for everyone. My code is safe for this general case.

@Niraj 2014-05-23 10:16:17

@gbn I agree your code is better for a scenario where my inner procedures can be called directly also by client apps. In my case it was not the case. In my case since I dont have transactions in inner procs and I use try catch always may be thats why I dont get error 266. Thanks for your sincere reply.

@dbenham 2016-06-03 17:13:34

Why use RAISERROR in your catch block instead of THROW? I thought THROW was the preferred option when using TRY/CATCH, and it seems simpler.

@dbenham 2016-06-03 17:33:04

Never mind. I now see that this answer predates SQL Server 2012, so TRHOW was not available. But perhaps it should be updated to use THROW, and add a note to use RAISERROR instead if the server version predates SS 2012.

@Vadzim 2017-02-22 23:34:57

@gbn, could you please estimate performance impact or other drawbacks of this altenative to simple cases:

@Bijimon 2019-04-17 00:15:20

XACT_ABORT ON setting essentially means any code in the catch block will NOT execute. The SP above works because the rollback is superfluous as mentioned in the first note by the author. If you added any error logging in the catch block, then use of XACT_ABORT flag I think will invalidate it. Can we safely eliminate xact_abort on statement from the template above?…

@Vadzim 2017-02-22 23:32:47

In case no special error handling needed in CATCH except rethrow and stored procs call chain isn't too long it may be suitable to use such simple template:

create procedure someNestedSP
begin transaction
-- do some work or call some other similar SP
commit transaction

It would also rollback root transaction with all "nested" ones in case of any error but the code is shorter and more straightforward than @gbn's solution. Still XACT_ABORT takes care of most issues mentioned there.

There may be addiotional overhead for transaction nesting but it may be not too high, I guess.

@gbn 2017-02-24 08:16:43

The TRY/CATCH blocks give more predictable error handling, especially where triggers are involved. Also, this pattern gives no option to trap, log or rethrow the error. Or to throw your own if data validation fails. And every one else uses a similar pattern to me…* Your choice, but this code would never go live in my work place.

@Aaron Bertrand 2010-01-15 18:54:52

I am not a Linq guy (and neither is Erland), but he wrote the absolute bibles on error handling. Outside of the complications Linq might add to your problem, all of your other questions should be answered here:

(Old link:

@Ben Tennen 2013-10-03 19:08:22

-- @Amanda method above doesnt return correct error number

  @ErrorMessage   nvarchar(4000),  
  @ErrorSeverity   int,  
  @ErrorState int,  
  @ErrorLine  int,  
  @ErrorNumber   int  

 SELECT 1/0; -- CATCH me  


  DECLARE @err int = @@ERROR  

  PRINT @err           -- 8134, divide by zero  
  PRINT ERROR_NUMBER() -- 8134  

    @ErrorMessage  = ERROR_MESSAGE(),  
    @ErrorSeverity = ERROR_SEVERITY(),  
    @ErrorState    = ERROR_STATE(),  
    @ErrorNumber   = ERROR_NUMBER(),  
    @ErrorLine     = ERROR_LINE()  

  -- error number = 50000 :(  
  RAISERROR (@ErrorMessage, @ErrorSeverity, @ErrorState, @ErrorNumber, @ErrorLine)  


-- error number = 8134  

@Patrick Szalapski 2014-02-12 16:34:07

You are right, but this belongs as a comment on Amanda's answer.

@Amanda 2013-04-29 05:57:44

To solve the issue of returning the error number and line number mentioned by @AlexKuznetsov, one can raise the error as such:

DECLARE @ErrorMessage NVARCHAR(4000)
DECLARE @ErrorSeverity INT
DECLARE @ErrorNumber INT

@ErrorSeverity = ERROR_SEVERITY(),
@ErrorState = ERROR_STATE(),
@ErrorNumber = ERROR_NUMBER(),
@ErrorLine = ERROR_LINE()

RAISERROR (@ErrorMessage, @ErrorSeverity, @ErrorState, @ErrorNumber, @ErrorLine)

Related Questions

Sponsored Content

22 Answered Questions

[SOLVED] Search text in stored procedure in SQL Server

26 Answered Questions

18 Answered Questions

[SOLVED] Function vs. Stored Procedure in SQL Server

0 Answered Questions

SQL Server Nested Transaction Management in Stored Procedure

1 Answered Questions

Using XACT_ABORT and TRY CATCH together in SQL Server break tSQLt Rollback

7 Answered Questions

1 Answered Questions


1 Answered Questions

0 Answered Questions

SET_XACT_ABORT ON in a transaction with rollback present in catch block

1 Answered Questions

Nested procedures with transactions

Sponsored Content