I am running a script in SQL Server Management Studio 2012 that involves a cursor. The script will go through a database table row-by-row, and combine data into single rows inserted into a second database table. I am confident that a cursor is the best way to go about this.
I have an issue that does not seems to be related to my code, because when it occurs, my only solution is to simply re-executed the code, and the error will not occur again.
I have pinpointed the error to the following:
FETCH NEXT FROM #theCursor INTO #variable, #anotherVariable, #etc...
The following error will occur
Could not complete cursor operation because the set options have changed since the cursor was declared.
Again, the extremely confusing problem is that this will not occur if I re-run the script after getting this error. I create a new query on the database, and I get the error every time. I then re-run the script, and it will work every time.
Another strange thing is that the error will only occur after this FETCH line has been executed about five times!
I have tried catching the error and simply re-invoking the entire procedure, but the error keeps occurring. The only solution I know of is to run the script again via SQL Server's 'Execute' command (F5 on keyboard).
I know there is not much here to go on. I myself do not have much to go on in specifics.
So, it turns out that I didn't know what types of things could be regarded as 'SET options', and what impact they could have.
In my script, I play around with the dateformat, as to deal with some inconsistent data in the database tables. It goes something like this:
set dateformat mdy
/* Do some DATETIME stuff with current format... */
set dateformat ymd
// ...
set dateformat dmy
// ...
set dateformat ymd
// ...
The solution was to not leave the dateformat as ymd, as I do above. Simply adding a set dateformat mdy at the end of all my date format shenanigans prevents the error from ever occurring. Strangely enough, ending off with set dateformat dmy does not work, but set dateformat mdy does.
I have this issue with my Execute SQL Task Failing. I am trying to execute a sp using an execute sql task. The execute statement is contained in a variable (exec [sp_name] par1, par2) that I have declared at the package level. Now inside the exec sql tak, I am calling this variable. Now when I try to execute this task, it fails and I get the following:
[Execute SQL Task] Error: Executing the query "EXEC CTL_ISRT_A 55,1" failed with the following error:
"Could not find stored procedure 'CTL_ISRT_A'.". Possible failure reasons: Problems with the query,
"ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
There is a stored procedure called "CTL_ISRT_A" in the db and I am able to execute it from SQL Server. This sp is inserting a new row in the table and it returns ##IDENTITY. Basically I need to store an integer value after the insert happens to a variable.
I tried setting the result set to a 'Single Row' and tried assigning the value to a variable but it didn't help. Could someone help me here?
Thanks in advance
I got a fix to this. Modified the stored procedure code and it began to work.
I have created EXECUTE SQL TASK in the SSIS package.
I am getting the Error called "INSERT failed because the following SET options have incorrect settings:
"ARITHABORT. Varify the set option are correct for use with indexed
views and/or indexes on computed columns or filtered indexes and query
notification"
But when i am trying execute ditectly in to SQL server management studio.It wont give any error.
Please let me know if you guys has come across this kind of issue.
Thanks
SET ARITHABORT in conjunction with SET ANSI WARNINGS controls how divide by zero and overflow errors are handled.
If you want to ignore the overflow and divide by zero, use this in front of your batch:
SET ARITHABORT OFF
SET ANSI WARNINGS OFF
If your database compatibility level is 80 or earlier, SET ARITHABORT must be on.
Is it possible to suppress warnings generated by T-SQL scripts? If so, how?
I know I can turn of the 'records affected' messages with
SET NOCOUNT ON
but is there an equivalent for warnings?
Eg:
Warning: Null value is eliminated by an aggregate or other SET operation.
If I'm expecting these errors, it helps to sift the real errors from the chaff in a big script.
Thanks.
See SET ANSI_WARNINGS {ON | OFF}
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;