I have an SP in SQL Server that looks like this (cleaned for display):
That is repeated three times. The 'Bunch o' stuff' is a series of inelegant queries that can take a bit of time to run. Since there are three of them, the SP overall takes a few minutes to run.
This SP is launched periodically as the final step of a web service. If I run it stand alone, it appears to run fine. When launched from the web service, I thought it was running fine, and it does appear to run fine at times, but I added some logging into the web service and have started seeing some unusual results creep into the log, so I thought I'd ask about them here.
One thing I am seeing is a series of messages (three, one for each part of the SP) like this:
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.
This is followed by the three statements from the PRINT statement. This is done in an odd pattern, because I would expect the first error message to be followed by the first PRINT phrase, then the next error message followed by the second PRINT statement, and so on, but that's not what's happening. I'm seeing the three error messages followed by the three PRINT phrases. I assume that this is something about how SQL Server tracks/manages messages.
The other oddity is the message itself. Since the SP usually does work, I'm wondering why it is failing. There's an obvious answer since the SP takes so long: It is possible for the web service to fire off the SP while the SP is already executing. What does SQL Server do in that instance? How does it handle concurrent calls to an SP?
There is clearly a BEGIN TRANSATION, and it appears to be working most of the time. Have I written that wrong in any way? Could one run of the SP be stepping on a second run of the SP and causing this?
Code:
BEGIN TRANSACTION
BEGIN TRY
'Bunch o' stuff here
COMMIT TRANSACTION
END TRY
BEGIN CATCH
ROLLBACK TRANSACTION
PRINT 'Some meaningful statement'
SET @result = 1
End CATCHThis SP is launched periodically as the final step of a web service. If I run it stand alone, it appears to run fine. When launched from the web service, I thought it was running fine, and it does appear to run fine at times, but I added some logging into the web service and have started seeing some unusual results creep into the log, so I thought I'd ask about them here.
One thing I am seeing is a series of messages (three, one for each part of the SP) like this:
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.
The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION.
This is followed by the three statements from the PRINT statement. This is done in an odd pattern, because I would expect the first error message to be followed by the first PRINT phrase, then the next error message followed by the second PRINT statement, and so on, but that's not what's happening. I'm seeing the three error messages followed by the three PRINT phrases. I assume that this is something about how SQL Server tracks/manages messages.
The other oddity is the message itself. Since the SP usually does work, I'm wondering why it is failing. There's an obvious answer since the SP takes so long: It is possible for the web service to fire off the SP while the SP is already executing. What does SQL Server do in that instance? How does it handle concurrent calls to an SP?
There is clearly a BEGIN TRANSATION, and it appears to be working most of the time. Have I written that wrong in any way? Could one run of the SP be stepping on a second run of the SP and causing this?
