views:

49

answers:

2

I'm looking at an error from one of our web applications, and it was calling a stored procedure that was responsible for updating a record in the database.

This stored procedure has worked for weeks with no issues. Then one day it started throwing errors, while debugging we found the cause to be inside the stored procedure.

It basically had a statement like this

Begin
  // Do Stuff

  Set
End

So the SET never actually set anything. For some reason this runs in perfectly fine on our server, and was running fine on a client server until earlier today when it decided to start complaining. (Incorrect Syntax error)

Is there any type of SQL Server setting that would cause this sudden change in behaviour?

Clarification - The SET has always been in the procedures. And running a SET by itself, or as a sole statement in a stored procedure does in fact work for me. This is the problem, it shouldn't work. So is there anything that would cause it to work when it should be failing?

+2  A: 

Executing "SET", by itself, will generate an error. I was originally going to suggest that you might have branching code (IFs, RETURNs, GOTOs, etc.) that caused the line to never be reached... but I find that I cannot create a stored procedure that contains this as a stand-alone statement.

If you script out the procedure and try to recreate it (with a different name), can it be created?

Might be worth posting that script, or as much of it as your are comfortable making public.

Philip Kelley
@Philip, actually executing SET by itself does not generate an error, at least not for me :P We do have branching code, but that same branch is always the first one executed. This isn't an edge case or anything. The procedure and branch that were being called are called frequently.
Brandon
+3  A: 

A procedure with a SET like that would normally fail to compile, even if the SET cannot be reached:

alter procedure dbo.testproc as
    begin
    return 1;
    set
    end

Incorrect syntax near the keyword 'SET'.

Since the alter fails, I can't see how the procedure could end up in your database in the first place?

Or maybe you were running in compatibility mode for SQL Server 2000 (which still allowed this.) Changing the compatibility mdoe to SQL Server 2005 or higher would then break the procedure.

Andomar
@Andomar, that procedure runs in for me just fine. (Assuming I create it first).
Brandon
@Brandon: Which version of SQL Server are you using? What's the compatibility mode of the database? (Database properties -> Options)
Andomar
I'm running SQL Server 2005, but the compatability for the database is set to SQL Server 2000.
Brandon
@Andomar, you are correct. The compatability version was what allowed it to work. Someone must have changed the client database this morning. Thanks!
Brandon
Good call. New to me.
gbn