SQL Server: INSERT/UPDATE/DELETE failed because th

I have this rather awkward problem:

For two weeks now, whenever after I've updated/created stored procedures using my SQL scripts, when these stored procedures are run, they fail with above error.

Other posts dealing with this problem didn't help in my case.

Here's a number of parameters, helping to exclude common solutions which do not apply in my case:

My stored procedure scripts work flawlessly on my laptop (SQL Server 2012, Windows Server 2008 R2).
My stored procedure scripts correctly create stored procedures on any other machine (which is our build machine, with SQL Server 2012 installed; our TEST server, with SQL Server 2005 installed, and our PROD server, with SQL Server 2005 installed). However, the stored procedures won't run on any other machine than mine.
I'm using a database backup of our production SQL Server (SQL Server 2005) on my machine (like any other machine here does).
Even the most basic stored procedure fails (e. g. DELETE myTable WHERE ID = @delID).
On every SQL Server installation I've checked, quoted identifier is set to OFF (!), both on server and on database level. So why do my stored procedures all of a sudden require to have this option set to ON?
I'm using SQLCMD to run my scripts. This gives me an option to dynamically set the server instance's database name in the USE statement.
My scripts only contain a USE statement and right after the ALTER PROCEDURE; or alternatively IF EXISTS (...) DROP PROCEDURE ... GO; CREATE PROCEDURE ...

This all worked for years now, but suddenly, since two weeks ago, stored procedures created with my scripts suddenly fail.

I know that I could manually set QUOTED_IDENTIFIER to ON in my scripts - but I don't want to. There is something wrong here. I want to know what that problem is.

What's happening here?

回答1:

SQLCMD sets the QUOTED_IDENTIFIER option to OFF by default. You can change it with -I option.

回答2:

Could it be that your stored procedure is now doing something on a table that has had an index added? I've had the same issue, and it's due to a new index on a computed column.