help - transaction control
From: roger (xrsr_at_rogerware.com)
Date: 07/14/04
- Next message: Steve Kass: "Re: Range query optimization help?"
- Previous message: Aaron W. West: "Re: Performance ideas - comparing first N chars of 2 TEXT columns"
- Next in thread: Andrew J. Kelly: "Re: help - transaction control"
- Reply: Andrew J. Kelly: "Re: help - transaction control"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 14 Jul 2004 04:05:36 GMT
I need to create (lots of) stored procedures that
operate transactionally, but may call each other or
be called as part of a larger operation.
My understanding of the way that transactions nest
is that I should be able to have each SP
begin and commit a transaction within itself,
and if the SP happens to be called from some context
that has begun a transaction, then the SP would participate
in that transaction context.
And that's exactly what I want.
Like here's a generic sort of structure of an SP then:
drop procedure trans_test
go
create procedure trans_test
as
begin
begin tran
print 'trancount 1= ' + str(@@trancount)
-- do stuff ...
if @@error <> 0
goto error -- something wrong, abort the transaction
-- everything OK, commit the transaction, or decrement trancount
commit tran
print 'trancount 2= ' + str(@@trancount)
return 0
error:
print 'error trancount 1= ' + str(@@trancount)
rollback tran
print 'error trancount 2= ' + str(@@trancount)
return -1
end
go
begin tran
declare @status int
exec @status = trans_test
if @status = 0 begin
print 'commit 1'
commit tran
end
And this seems to work right if trans_test does its commit.
But, if instead it takes the goto error path and rolls back
the transaction, then I get the following messages printed via isqlw
trancount 1= 2
error trancount 1= 2
Server: Msg 266, Level 16, State 2, Procedure trans_test, Line 16
Transaction count after EXECUTE indicates that a COMMIT or ROLLBACK
TRANSACTION statement is missing. Previous count = 1, current count = 0.
error trancount 2= 0
As far as the transaction handling goes, it does seem
that my SP is doing the right thing, but what's with the messages?
I understand that error handling is problematic with T-SQL, but
I think I'm working within its capabilities here.
Any ideas, or tips?
Thanks
- Next message: Steve Kass: "Re: Range query optimization help?"
- Previous message: Aaron W. West: "Re: Performance ideas - comparing first N chars of 2 TEXT columns"
- Next in thread: Andrew J. Kelly: "Re: help - transaction control"
- Reply: Andrew J. Kelly: "Re: help - transaction control"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|