存储过程失败，但在手动运行时可正常工作

Question

I have a stored procedure in SQL Server 2008 R2. It was working correctly, but it stopped working (I did not change the code).

It is something difficult to explain, specially because I can not share the stored procedure's code (company's rules). I will try to explain it as much as possible.

This stored procedure is executed by a software, this software calls two stored procedures. One of the stored procedures works correctly and the another one "fails" (it doesn't do anything and not return any error). Both stored procedures do similar things such as update and insert information, from parameters, in some tables. If I check the software's logs I can see that this software is calling both stored procedures correctly. In fact, the stored procedure does not return any error, it just does not do anything.

When I run this stored procedure manually, I use the same parameters that the software should pass and it works correctly.

I simulated a real case and the software called both stored procedures, one works and the another one did not do anything. Then, I executed the second stored procedure manually with the same parameters and it worked correctly.

In addition, the database's user has enough permission (I guess it, because it was working correctly).

Another important thing is that I have two environments with the same databases. The software calls both stored procedures in both environments. In one of the environments it works correctly and the another environment the software calls both stored procedures, but one of them does not do anything as I have explained here.

Regards and thanks!

Answer 1

First, try to run the stored proc using Profiler to get exactly what is being sent, it may not be sending what you think it should.

Next check the structure of the two databases for the tables/views referenced, any functions in the procs. Make sure to also check permissions. Script the stored procs in both databases and compare. When database on two servers have an issue like this it is often that the servers are not in sync with the exact code they should have.

Also the data may be different resulting in no data that needs to be acted on by the stored proc in one server.

Answer 2

One reason this can happen is the use of temp tables; if they are not available, it may fail, and the scope works differently in a stored procedure than in an interactive session.