CATCH handler causes "severe error occurred" in SqlClient when error comes from CLR PROCEDURE with ExecuteAndSend - by Erland Sommarskog

Status : 

 


1
0
Sign in
to vote
ID 781468 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 3/15/2013 3:13:52 PM
Access Restriction Public

Description


You have a CLR procedure that uses ExecuteAndSend to execute a batch. You call this CLR procedure from a T-SQL procedure. The call to the CLR procedure is in with TRY-CATCH in T-SQL. The batch you call from the CLR raises an error.

There are two alternatives:
1) The CLR procedure rethrows the error.
2) The CLR procedure swallws the error and does not rethrow.

In the first case, execution is transferred to the CATCH handler, in the second not. However any attempts to run SELECT statements only gives "rows affected", but no result set. And the final output is
Msg 0, Level 11, State 0, Line 0
A severe error occurred on the current command.  The results, if any, should be discarded.

Note, this behaviour only happens with SqlClient; when running from ODBC everything works as expected. Thus, this could be an error in SqlClient. I've filed for the engine, as the engine could be generating in a correct TDS stream.

Also notable, I originally reported this problem in April 2005, see 
https://connect.microsoft.com/SQLServer/feedback/details/125835/catch-handler-causes-severe-error-occurred-in-sqlclient-when-error-comes-from-clr-procedure
and the bug was closed as Fixed to be shipped with RTM. But the behaviour is the same in SQL 2005 SP1.

One could dispute whether there is an actual use case here. The one case I can see is advanced INSERT-EXEC scenarios, but admittedly it is not compelling. I neverthelless decided to file the bug to bring up the issue.


Sign in to post a comment.
Posted by Microsoft on 4/19/2013 at 11:25 AM
Hello Erland,
Thanks for reporting the issue. The behavior is not a regression and doesn't meet the bar for fixing bugs in the current/future version of SQL Server. So I am closing this as "won't fix". Presumably, users can avoid the issue easily by rethrowing the error from the CLR procedure.

--
Umachandar, SQL Programmability Team