UPDATE failed because the following SET options have incorrect settings: 'QUOTED_IDENTIFIER' - sql-server-2005

I am having a problem with an update stored procedure. The error is:
UPDATE failed because the following SET options have incorrect settings: 'QUOTED_IDENTIFIER'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or query notifications and/or xml data type methods.
SQL State: 42000
Native Error: 1934
Unfortunately, there are no indexed views, computed columns, or query notifications for this table. This Stored Procedure was running fine for past couple of days and since today has been returning this error.
Is there any suggestion that would help in identifying the problem?
Note: If I set the quoted_identifier to ON and rerun the CREATE PROCEDURE, the issue will be fixed (for now). But I want to understand what triggered this issue in the first place.

To avoid that error, I needed to add
SET ANSI_NULLS, QUOTED_IDENTIFIER ON;
for all my stored procs editing a table with a computed column.
You don't need to add the SET inside the proc, just use it during creation, like this:
SET ANSI_NULLS, QUOTED_IDENTIFIER ON;
GO
CREATE PROCEDURE dbo.proc_myproc
...

I got this error when I tried to run an sql file via the command line with sqlcmd:
sqlcmd -i myfile.sql
By default QUOTED_IDENTIFIER is set to OFF when using this command line tool and you will get the same error (no matter that in the SSMS it may be set to ON and the same script will pass).
So indeed the solution is to add this QUOTED_IDENTIFIER ON to your sql file like Jim suggested, or explicitly specify the flag -I:
sqlcmd -i myfile.sql -I

We cannot create a indexed view by setting the quoted identifier off. I just tried it and SQL 2005 throws an error straight away if it is turned off:
Cannot create index. Object 'SmartListVW' was created with the following SET options off: 'QUOTED_IDENTIFIER'.
As gbn said, rebuilding the indexes must be the only other way it got turned off.
I have seen lots of articles saying it must be on before creating index on views. Otherwise you would get an error while inserting, updating the table, but here I can get the error straight away, so sql engine won't allow to create index on views by setting it to off, per this msdn link.
I have asked a similar question here in stack sometime ago...
EDIT
I turned off the global queryexecution (in editor) ANSI settings and ran the index script in new editor, this time also it throws the same error. So it's clear we can't create indexes on views by turning off quoted_identifier.

I'm late to this party but had this error and wanted to share it.
Our problem was recurrent but random so we knew it wasn't an object that had been created incorrectly.
We finally tracked it down to an ODBC connection on one of the servers in our Citrix farm. On that server, the ODBC in question had had its QUOTED_IDENTIFIERS turned off (unchecked). On all the other servers, it was checked as expected. We turned the option on and the problem was instantly solved.

I got this error when I run SQL Agent Job, which has 3 steps T-sql scripts.
Msg 1934, Sev 16, State 1, Line 15 : UPDATE failed because the
following SET options have incorrect settings: 'QUOTED_IDENTIFIER'.
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. [SQLSTATE 42000]
I added
SET ANSI_NULLS, QUOTED_IDENTIFIER ON; to the top of the Agent Job and that solved the issue.

Some thoughts:
Did indexes get rebuilt? If you do index maintenance using DMO, then quoted_identifier will not always be preserved. It can be a pain to track down and was a particular problem is SQL Server 2000 until SP4 or so.
However, I've seen on SQL Server 2005 some time ago too.

SELECT
OBJECT_NAME (sm.object_id) AS [Name],
sm.uses_ansi_nulls,
sm.uses_quoted_identifier,
N'SET ANSI_NULLS, QUOTED_IDENTIFIER ON;
--change the below CREATE to an ALTER.
GO
' + sm.definition AS PossibleFixingStatement
FROM
sys.sql_modules AS sm
WHERE
1 = 1
AND
(
sm.uses_ansi_nulls <> 1
OR sm.uses_quoted_identifier <> 1
)
AND NOT EXISTS
(
SELECT
*
FROM
sys.objects AS o
WHERE
o.is_ms_shipped = 1
AND o.object_id = sm.[object_id]
)
ORDER BY
sm.uses_ansi_nulls,
sm.uses_quoted_identifier;
Query to identify the affected objects. Part of the sp_blitz procedure mentioned here at https://github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit/issues/1698

I got this error today running a stored procedure in SSMS. Disconnecting from the server and reconnecting with a new session solved the problem for me. The SP I was running had never had this problem before.

I got the same error running this query in the Job Scheduler SQL Server Agent
UPDATE [Order]
SET OrderStatusID = 100
WHERE OrderStatusID = 200
AND OrderID IN (
[...]
)
I solved removing the [ ] characters from [Order]:
UPDATE Order
SET OrderStatusID = 100
WHERE OrderStatusID = 200
AND OrderID IN (
[...]
)
No more errors

I got the same error, had to add a couple of settings to get it resolved:
SET ANSI_NULLS ON;
SET ANSI_PADDING ON;
SET ANSI_WARNINGS ON;
SET ARITHABORT ON;
SET CONCAT_NULL_YIELDS_NULL ON;
SET NUMERIC_ROUNDABORT OFF;
SET QUOTED_IDENTIFIER OFF;
SET NOCOUNT ON;

Related

Can't import northwind sql file onto DB Browser for SQLite

I seem to get this error message.
[Error importing data: Error in statement #1: near "S":syntax error. Aborting execution and rolling back.]
(https://i.stack.imgur.com/IzRvb.png)
I looked into the SQL file. These are the first few lines:
Select * from Shippers
/*
MS SQL Server
Setup script for SQL Practice Problems
Database: Northwind_SPP
*/
Set nocount on
GO
/****** Object: Table [dbo].[Categories] ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Categories](
...
Can't seem to find the "Syntax error" especially in line 1.
The Northwind SQL examples are for sql-server, which may have a slightly different syntax than sqlite. You won't be able to use them with an RDBMS they were not intended for.
Using https://github.com/jpwhite3/northwind-SQLite3 to download.
Started DBeaver.
Created connection to the download and :-

Query Store is configured but none of my queries under any load show up

SQL Server 2017 Enterprise Query Store is showing no data at all but shows READ_ONLY as the actual mode
The one similar question in this forum has an answer that doesn't apply - none of the exclusions are present.
I ran:
GO
ALTER DATABASE [MyDB] SET QUERY_STORE (OPERATION_MODE = READ_ONLY, INTERVAL_LENGTH_MINUTES = 5, QUERY_CAPTURE_MODE = AUTO)
GO
I also ran all these, having referenced the link below, DB context is MyDB:
https://learn.microsoft.com/en-us/sql/relational-databases/performance/best-practice-with-the-query-store?view=sql-server-2017
ALTER DATABASE MyDB SET QUERY_STORE = ON;
SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
max_storage_size_mb, readonly_reason, interval_length_minutes,
stale_query_threshold_days, size_based_cleanup_mode_desc,
query_capture_mode_desc
FROM sys.database_query_store_options;
ALTER DATABASE MyDB SET QUERY_STORE CLEAR;
-- Run together...
ALTER DATABASE MyDB SET QUERY_STORE = OFF;
GO
EXEC sp_query_store_consistency_check
GO
ALTER DATABASE MyDB SET QUERY_STORE = ON;
GO
No issues found. The SELECT returns matching Actual and Desired states.
I am a sysadmin role member, who actually sets up all 30+ production servers, and this is the only miscreant.
The server is under heavy load and I need internal-eyes on it, in addition to Solarwinds DPA. I've also run sp_blitzquerystore but it returns an empty rowset from the top query, and just the two priority 255 rows from the 2nd.
What on earth did I do wrong? Any clues, anyone, please?
I know this is an old post but for those who come here looking for answers: I do see you ran the query with OPERATION_MODE = READ_ONLY. This would put it into a read-only mode - a mode in which it only reads what is stored in the query store without collecting any additional information. There will be no information shown if the query store has never been in READ_WRITE mode.
If it has been in READ_WRITE mode before and you are still not seeing anything, it is possible that the heavy load on the server is pushing query plans out of the cache.

Turning ANSI_WARNINGS off permanently at the database level with alter command not working

My goal is to turn off ANSI_WARNINGS at the database level permanently. I understand the risks.
The command that I'm using is
ALTER DATABASE <DB_NAME>
SET ANSI_WARNINGS OFF;
However, when I try to insert a big value( beyond what is defined for the column) into a column I still get
String or binary data would be truncated. The statement has been
terminated.
Please help me with making the alter command work permanently

SQL Server Stored Procedure Fails due to use of XML/ ANSI_NULLS, QUOTED_IDENTIFIER options

I have a stored procedure which takes an XML parameter and inserts the data into multiple tables. If I run the stored procedure into a database using a SSMS query window, everything works fine. However, we have a custom installation program that is used to deploy stored procedures to databases, and when this is used, execution of the sp fails with this error:
INSERT failed because the following SET options have incorrect settings:
'ANSI_NULLS, QUOTED_IDENTIFIER'. Verify that SET options are correct for use with
indexed views and/or indexes on computed columns and/or query notifications
and/or xml data type methods.
The custom installation program does not use the correct settings when scripting in the stored procedures.
Setting these ( SET ARITHABORT ON; SET QUOTED_IDENTIFIER ON; SET ANSI_NULLS ON;) within the sp has no effect:
I have also tried setting these options for the open connection just before calling the sp in the code. This again does not have the desired effect.
It appears that the settings on the connection to the database while the sp is being run in to the database are what matters, not the settings when the sp is used.
I have experimented by playing with these settings in SSMS options, and this does appear to be the case. I would just like someone to confirm that this is definitely the case (if there is a way around I would love to hear it, but I'm not hopeful)
Unfortunately altering the installer program is not an option for me at the present time, so I'm looking at having to roll back a couple of weeks work; so if I do have to do this I want to be really sure (and have some evidence to back me up) that this is the only option
The settings applied with those at CREATE or ALTER time and are ignored at runtime.
SSMS has correct settings by default (so does sqlcmd, osql etc).
From BOL, CREATE PROC, "Using SET Options"
The Database Engine saves the settings
of both SET QUOTED_IDENTIFIER and SET
ANSI_NULLS when a Transact-SQL stored
procedure is created or modified.
These original settings are used when
the stored procedure is executed.
Therefore, any client session settings
for SET QUOTED_IDENTIFIER and SET
ANSI_NULLS are ignored when the stored
procedure is running. Other SET
options, such as SET ARITHABORT, SET
ANSI_WARNINGS, or SET ANSI_PADDINGS
are not saved when a stored procedure
is created or modified.

SET NOCOUNT OFF or RETURN ##ROWCOUNT?

I am creating a stored procedure in Sql Server 2008 database. I want to return the number of rows affected. Which is a better option SET NOCOUNT OFF or RETURN ##ROWCOUNT?
ALTER PROCEDURE [dbo].[MembersActivateAccount]
#MemberId uniqueidentifier
AS
BEGIN
-- Should I use this?
SET NOCOUNT OFF;
UPDATE [dbo].Members SET accountActive = 1 WHERE id = #MemberId;
--Or should I SET NOCOUNT ON and use the following line instead?
--return ##ROWCOUNT;
END
I know that both work, but which is a better choice and why?
After some trying I am coming to a conclusion that SET NOCOUNT is OFF by default inside stored procedures. Is it possible to change this behavior inside my database?
Use ##RowCount. It's explicit and transparent, it is entirely controlled by your code rather than a built-in behaviour.
The NOCOUNT option can be manually set to default to ON (Optons>Query Execution>SQL Server>Advanced). If you set it this way but then declare SET NOCOUNT OFF in your stored procedure then that local setting takes precedence.
Don't use RETURN for values. By convention RETURN from stored procedures is for error codes, 0 meaning no error and non-0 meaning some kind of problem. If you need data back, the appropriate way to do it is with an OUTPUT parameter. It's a little counter-intuitive based on other languages' use of return.
I know that having SET NOCOUNT ON would make a DataAdapter think there was a concurrency conflict.
You can read about it on MSDN. If the code is going to be used by DataAdapters then obviously don't use SET NOCOUNT ON.
It looks like SqlCommand also has this behaviour, which I guess is the reason why the DataAdapter has a problem (as under the hood it will use a Command object).
Reasons for using SET NOCOUNT ON/OFF:
To control the stack overflow while inserting rows into any table.
Passing the T-Sql messages while executing of the queries or nested queries.
To Show or viewing the latest queries executed.
To get information on the latest record escalation.
Why we use SET NOCOUNT on/off ---
Ans : we can understand this by following steps
step 1 : execute query "Select top 10 * from table name".
step 2 : open message window it shows a message "10 rows affected". it creates extra overheads and extends our execution time.
step 3 : to overcome this extra overheads we use SET NOCOUNT ON. If it is On then it will never count the number of row returns instead it sows a message commands completed successfully.
step 4 : By default NOCOUNT is ON then it counts the number of returned rows that is why my suggestion that it should off during creating new procedures to get better performance from database server.