Rolling Back Strategy

  • Hi all

    I do have One stored procedure that calls other stored procedures, each on which might call another stored procedure. However, am making begin transaction, commit transaction and rollback only in the main stored procedure, unfortunatlly, i have founf that, if the last exectuted "SP" has encountered a problem the main SP will not rollback as long as it wasn't generated in it, rather than that it commits the transaction! :w00t:

    I gently, however, ask u to aid me!!

    Thx in advanced

  • Probably something's missing in the error handling. Can you post the outer stored proc?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • ammarghanem921 (1/31/2009)


    Hi all

    I do have One stored procedure that calls other stored procedures, each on which might call another stored procedure. However, am making begin transaction, commit transaction and rollback only in the main stored procedure, unfortunatlly, i have founf that, if the last exectuted "SP" has encountered a problem the main SP will not rollback as long as it wasn't generated in it, rather than that it commits the transaction! :w00t:

    I gently, however, ask u to aid me!!

    Thx in advanced

    Rollbacks are awefully expensive... especially on transactions that are so long and have so many procs involved. The best way to do this would be to know all of the answers before you even think of a insert or update. Calculate everything ahead of time and once everything has been validated as correct, THEN start a transaction that will very quickly do the necessary updates/inserts/delets using, perhaps, a temp table as the driver and source of the validated data. Your current method is RBAR on steriods with the full capability of producing deadlocks.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • CREATE PROC SP_validatePayment

    @AmountPaid numeric(9),

    @MethodOfPayment int ,

    @ListOfBillsPaid nvarchar(4000)

    Begin

    DECLARE @TranStarted bit

    SET @TranStarted = 0

    IF( @@TRANCOUNT = 0 )

    BEGIN

    BEGIN TRANSACTION

    SET @TranStarted = 1

    END

    ELSE

    SET @TranStarted = 0

    -------------------------------------

    if valid(/*validationProcess*/)

    BEGIN

    EXEC SP_InsertPayment @AmountPaid ,@MethodOfPayment

    END

    -------------------------------------

    IF( @@ERROR <> 0 )

    GOTO Cleanup

    IF( @TranStarted = 1 )

    BEGIN

    COMMIT TRANSACTION

    END

    return 0

    Cleanup:

    IF( @TranStarted = 1 )

    BEGIN

    SET @TranStarted = 0

    ROLLBACK TRANSACTION

    END

    RETURN -1

    end

    GO

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply