SQL Server profiler shows stored procedure being called but is not actually executed

Question

I have a problem I will try to summarize it:

I run SQL Server Profiler to track the call of a stored procedure. It shows that the stored procedure is being called but is not actually being executed.

I know that because the stored procedure updates a column to avoid concurrency and each call to the stored procedure needs to use different (updated) parameters, so when I run directly the call from the profiler into SSMS it runs okay, then if I run it for the second time it gives the concurrency problem showing that the first time it wasn't actually ran.

I ran out of ideas on why is this happening. SQL Server Profiler shows the stored procedure being called but is not actually being called!

Thanks and regards.

EDIT: more info

• The stored procedure works perfectly locally
• If we run the EXACT same line that the profiler shows, in the target DB traced by the profiler, the stored procedure works perfectly.
• I run it with Entity Framework. However, before calling that stored procedure I call some others stored procedures, then I call that problematic stored procedure and then I save changes. Changes from the previous stored procedures are saved as well.
• When I call the stored procedure locally I get an OK, if I run the stored procedure with the same values I get a "concurrency error" because each call has to use a different value in some parameter (concurrency). Knowing that, if I run the profiler in my local DB I see the stored procedure being executed, then I try to run the exact same line and I get a concurrency error, meaning that the stored procedure has been ran correctly. When I run the profiler in the target DB I see the stored procedure being executed, then I try to run the exact same line and I get an OK meaning that it wasn't never ran. If I try to run that line again, then I get the concurrency problem.

Basically is some weird thing, probably the weirdest I have seen for now. The SQL Server Profiler shows the stored procedure being called but apparently it never finishes but the stored procedure is perfectly ok knowing the fact that if I run directly the EXACT SAME call that the profiler showed, it will run ok.

Is a little bit weird but I hope that clarifies it a little bit more.

Answer 1

We fixed the problem by changing the setting 'ARITHABORT'.

The wrost thing to try to find the problem was that the stored procedure call that didn't work from entity framework, worked from SSMS and that was because SSMS overrides some of the options and we didn't see that problem.

We installed the old application into the same environment (same DB) and at some other different place of the app, it showed this error:

UPDATE failed because the following SET options have incorrect settings: 'ARITHABORT'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.

So the problem was with an update, but that update didn't come directly from the SP but from a trigger triggered by a trigger triggered by the SP, so we didn't have any log of that, as crazy as it sounds.

Luckily for us the old app we try to replace "fixed" the problem by hinting us into the right direction.

Thanks everyone for your help!

Answer 2

I just had exactly the same issue but in my case the resolution was different.

SQL Profiler was showing a stored procedure being called e.g. exec NameOfProcedure @id=1234 which may insert a new record with the provided ID.

However when viewing the contents of the SQL table no record was inserted and if you copied and pasted the above command into a new SSMS window it executed correctly and the record was then added to the table.

The reason turned out to be that the database user did not have EXECUTE permissions on the database but SQL Profiler did not show that the command failed as it would have, had there been a syntax error in the code.

The fix was to create a new role with EXECUTE permissions and assign it to the user which resolved the issue and the stored procedures began working again:

CREATE ROLE ExecuteProcedures
GRANT EXECUTE TO ExecuteProcedures
EXEC sp_addrolemember 'ExecuteProcedures', 'UserWithIssue';  

The Execute permissions could have also been assigned directly to the user but this way is more visible and better to assign permissions to groups.