Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1473
  • Last Modified:

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
0
pn77
Asked:
pn77
  • 6
  • 4
1 Solution
 
Joe WoodhousePrincipal ConsultantCommented:
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.
0
 
pn77Author Commented:
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,

0
 
Joe WoodhousePrincipal ConsultantCommented:
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!
0
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

 
pn77Author Commented:
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.


0
 
pn77Author Commented:
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
0
 
Joe WoodhousePrincipal ConsultantCommented:
I wonder if this would do the job:

   exec @RcIn = proc2   parameter, parameter

   if (@@error != 0) or (@RcIn != 0)
        goto ErrorHandler

I'm not sure what the return status will be for an error that halts the proc. As you say, testing for @@error inside proc2 doesn't help because in the case of a termination it never gets that far. This covers both bases.
0
 
pn77Author Commented:
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,
0
 
Joe WoodhousePrincipal ConsultantCommented:
Ok, this officially beats me now!! 8-)
0
 
ChrisKingCommented:
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
0
 
pn77Author Commented:
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,
0
 
pn77Author Commented:
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,
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 6
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now