Link to home
Start Free TrialLog in
Avatar of pn77
pn77Flag for United States of America

asked on

transaction rollback during unexpected error

Hi,
I have a stored proc that inserts into a some tables within a transaction. In this proc I check the @@error to see if it's not equal to 0 after each insert. If it's not equal to zero, then I do a rollback as follows:
if (@@Error !=0 and @@trancount > 0)
                begin
                        rollback tran
                end

The problem I am having is if there was an unexpected error like an implicit conversion error, Sybase does not continue processing the procedure and exits without doing the rollback.
Doe anyone know how I can catch all errors to make sure it will do a rollback?

Thanks in advance
Avatar of Joe Woodhouse
Joe Woodhouse

Do the transaction management outside the procedure, and test the procedures return status? Commit or rollback according to the status. Errors like conversions will still leave a trappable return code.
Avatar of pn77

ASKER

Actually I am doing that and in the calling procedure, I check the return code, if it's !=0 then I would goto the error handler which checks the @@trancount > 0 and then does a rollback. I have nested transactions. So in the calling proc, it started a transaction and it called stored proc 2 which also has a transaction that completed and committed successfully, then it calls proc 3 which starts a transaction and fails with the implicit conversion error. I would expect the calling proc to handle the rollback and roll back to the outermost begin Tran, but for some reason the transaction in proc 2 did not get rolled back.

Thanks,

Are you capturing the return status separately to @@error?

Some errors could immediately halt the executing procedure without causing the rollback, but surely that would be reported by the return status? Try explicitly setting a (positive) return status at the end of proc 2 and proc 3, and test for that in the calling proc...?

I agree it's a bit weird!
Avatar of pn77

ASKER

I am checking the return code separate from the @@error:

exec @RcIn = proc2   parameter, parameter
               
if (@RcIn != 0)
     goto ErrorHandler

The ErrorHandler does the rollback if @@trancount > 0

Yet still every time we get this error, it does not do the rollback of that data inserted from proc2.


Avatar of pn77

ASKER

In proc2 and proc3, I do explicitly set the return status to 100 if it fails to do the insertion. Thus, after the insert statement, I check the @@error and then set the return status to 100 then goto the errorhandler to rollback and return the return status. (It doesn't even run this code because the stored proc halts). I assumed that the calling stored proc would catch the return code if it checks (@RcIn != 0) and do a rollback, but for some reason it does not.

                if (@@error != 0)
                begin --{
                        select    @RcOut = 100
                        goto ErrorHandler
                end --}

  ErrorHandler:
                if @@trancount > 0
                begin
                        rollback tran
                end
                return @RcOut
ASKER CERTIFIED SOLUTION
Avatar of Joe Woodhouse
Joe Woodhouse

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of pn77

ASKER

Joe,
I actually did try that as well, but still it did not rollback.
I am now trying to look through my code carefully and debug using RapidSQL.

Thanks,
Ok, this officially beats me now!! 8-)
it sounds like some arithmatic overflow on one of the parameter being passed to the procedure, so it is never actually being called

have you selected your parameters out to check the values before the exec ?
you also seem to be using unnamed parameters in the call, can be misleading to which value is going where
Avatar of pn77

ASKER

Thank you for your reply.
The posted sql is not my actual code. I was just giving an example.
I actually did name my parameters. The error is an implicit conversion error and it occurs in the procedure where it's trying to do an insert into a field that is a datetime. I have verified that it has entered the procedure and then halts when it tries to do the insert. I know why I got this error and I have fixed it so it does not give the implicit conversion error. The issue I had was that the transactions did not get rolled back when the unexpected error occurred.
I just want to be able to set up my transaction management so that everything gets rolled back to the outermost begin trans in case of other unexpected errors.

Thanks,
Avatar of pn77

ASKER

After looking through this again, I have mistaken a record that was inserted to be the record that my proc inserted. I found that my proc was doing the transaction rollback as expected. I was just looking at the wrong record in the table.....duhhhhh.
I'm sorry for wasting everyone's time.

Thanks,