Errors that abort batch but not transactions cannot be caught when the CLR is on the call stack - by Erland Sommarskog

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 778911 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 2/10/2013 1:01:27 PM
Access Restriction Public


You have some T-SQL code that calls a CLR stored procedure which in its turn invokes some T-SQL code. This T-SQL causes an error that aborts the batch, without rolling back the transaction (if there is any). Currently, to my knowing, there are two such errors, of which one is the new ;THROW statement.

It turns out that this error cannot be caught, neither in the CLR code, nor in the upper-level SQL code, but the error is always passed to the client. For whatever reason, the error message has a leading newline.

One can also note that if the T-SQL code starts a transaction, the transaction survives the ordeal. The normal behaviour when the CLR exits with a different trancount than on entry that the transaction is silently rolled back (if there was no active trans on entry) or raises an error (if there was a trans prior to the call to the CLR.)

The behaviour only appears if XACT_ABORT is OFF.

Sign in to post a comment.
Posted by Microsoft on 4/22/2013 at 12:27 PM
Hello Erland,
We looked at this issue and it doesn't meet the bar for fixing the bug in the next major release of SQL Server. SO I am resolving this bug as "won't fix". We will look at it again if we get more feedback.
Only thing I can suggest is to use XACT_ABORT ON for your session.

Umachandar, SQL Programmability Team
Posted by Microsoft on 2/17/2013 at 12:55 PM
Thanks for reporting this, Erland. We are looking at this now, and will get back to you when we have analyzed it further.