存储的proc失败，出现SQL错误3621，在ssms中运行良好，并且如果删除并重新创建

Question

I have a stored proc that is called by a .net application and passes an xml parameter - this is then shredded and forms the WHERE section of the query.

So in my query, I look for records with a documentType matching that contained in the XML. The table contains many more records with a documentType of C than P.

The query will run fine for a number of week, regardless of if the XML contains P or C for documentType. Then it stops working for documentType C.

I can run both queries from SSMS with no errors (using profiler to capture the exact call that was made). Profiler shows that when run from the application, the documentType C query starts a statement then finishes before the statement ends, and before completing the outstanding steps of the query.

I ran another profiler session to capture all errors and warnings. All I can see is error 3621 - The statement has been terminated. There are no other errors relating to this spid, the only other things to be picked up were warnings changing database context.

I've checked the SQL logs and extended events and can find nothing. I don't think the query relates to the data content as it runs in SSMS without problems - I've also checked the range values for other fields in the WHERE clause and nothing unusual or untoward there. I also know that if I drop and recreate the procedure (ie exact same code) the problem will be fixed.

Does anyone know how I can trace the error that is causing the 3261 failure? Profiling does not pick this up.

Answer 1

In some situations, SQL Server raises two error messages, one is the actual error message saying exactly what is happening and the other one is 3621 which says The statement has been terminated .

Sometimes the first message get lost specially when you are calling an SQL query or object from a script.

I suggest you to go through each of your SQL statement and run them individually.

Another guess is you have a timeout error on your client side. If you have Attention event on your SQL Server trace, you can follow the timeout error messages.