if I have SET ANSI_WARNINGS OFF in one stored procedure to get rid of a warning, it only takes effects of that stored procedure and has no impact on other ones, which means in other stored procedures, the ANSI_WARNINGS is still on.
What if I want to turn it off for all stored procedures?
Why it is default on? How could I know that?
Do other settings(e.g., NOCOUNT) in sql server work the same way?
Thanks a lot.
It will be great if anybody can share articles about common characteristics of these settings with me.
It's possibly worth point out that not only does it NOT affect other stored procedures, it only affects statements following the SET operation
e.g. run this and you will see that the option is turned off then on and then off again.
CREATE TABLE test
(
intvalue int NULL
)
INSERT INTO test VALUES (1)
INSERT INTO test VALUES (NULL)
SET ANSI_WARNINGS OFF
SELECT COUNT(intvalue) FROM test
-- (1 row(s) affected)
SET ANSI_WARNINGS ON
SELECT COUNT(intvalue) FROM test
-- (1 row(s) affected)
-- Warning: Null value is eliminated by an aggregate or other SET operation.
SET ANSI_WARNINGS OFF
SELECT COUNT(intvalue) FROM test
-- (1 row(s) affected)
DROP TABLE test
From BOL:
SQL Server includes the ANSI_WARNINGS database option. This is
equivalent to SET ANSI_WARNINGS. When SET ANSI_WARNINGS is ON, errors
or warnings are raised in divide-by-zero, string too large for
database column, and other similar errors. When SET ANSI_WARNINGS is
OFF, these errors and warnings are not raised. The default value in
the model database for SET ANSI_WARNINGS is OFF. If not specified, the
setting of ANSI_WARNINGS applies. If SET ANSI_WARNINGS is OFF, SQL
Server uses the value of the is_ansi_warnings_on column in the
sys.databases catalog view.
You can read about it in BOL (F1 in Management Studio) or on MSDN http://msdn.microsoft.com/en-us/library/ms190368.aspx
NOCOUNT works the same.
Related
I have two connections to the same db on the same server, with the same user,
as open windows in Sequel Server Management studio.
On the first I run:
BEGIN TRANSACTION T1
SET ANSI_PADDING ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON;
SET NUMERIC_ROUNDABORT OFF
SET ARITHABORT OFF
SET ANSI_WARNINGS ON
SET ANSI_NULLS ON
DELETE from GPSData where GPSDateTime BETWEEN '2014-06-09' AND '2014-06-11'
COMMIT TRANSACTION T1
and the error is:
Msg 1934, Level 16, State 1, Line 8
DELETE failed because the following SET options have incorrect settings: 'ANSI_NULLS, CONCAT_NULL_YIELDS_NULL, ANSI_WARNINGS, ANSI_PADDING'. 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.
When I run the same transaction on the other connection, the error is:
The DELETE statement conflicted with the REFERENCE constraint "FK_GPSUnit_GPSData". The conflict occurred in database "PLATO_PEP", table "dbo.GPSUnit", column 'GPSDataID'.
The statement has been terminated.
The second error I expect to see. How can the first connection give an ANSI_PADDING... error, when the same settings work on the second connection?
I'm running SQL Server 2012.
I have a create procedure statement:
USE [dbname]
GO
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[Test]') AND type in (N'P', N'PC'))
DROP PROCEDURE [dbo].[Test]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[Test]
AS
SELECT 1
When I run this with dbname equals one database, I get:
(1 row(s) affected)
When running it dbname equals another database on the same server, I get:
Command(s) completed successfully.
Obviously this is a database setting or something specific to the database, but I can't seem to find anything. Does anyone know what is causing the difference?
Thanks in advance.
This may be cause of DDL trigger existence. as you mentioned in your comments, one of the triggers has SET NO COUNT ON, which will be stops the message that shows the count of the number of rows affected by a Transact-SQL statement or stored procedure from being returned as part of the result set. if you comment it, or add it to the other trigger too, you will see the same results for both above mentioned scenarios.
I have the following stored procedure:
ALTER PROCEDURE [dbo].[spTitle_GetTitleById]
(
#TitleId INT
)
AS
BEGIN
SET NOCOUNT ON;
SELECT
Id,
Name,
Active
FROM
Title
WHERE
Id = #TitleId
END
I was told to use SET NOCOUNT ON; if I don't want messages to be returned. I ran this stored procedure through SQL Server Management Studio 2008 and I got the following message:
(1 row(s) affected)
This is still a message. One of our DBAs said that this will be the case, but when it is run through an application it will not return any messages. Is there a way that I can test to see if messages were returned or not when I use SET NOCOUNT ON; I don't want to assume, I want to know.
I right clicked the stored procedure and selected Execute Stored Procedure... I then set it to OFF, and I got:
(1 row(s) affected)
(1 row(s) affected)
So setting it to ON or OFF it still brought back messages in the Messages tab in the results panel.
Just another question, when will it be wise (in what scenarios) to use SET NOCOUNT OFF;?
SET NOCOUNT ON is reset when the procedure exits and it goes up the call stack. When you execute the procedure from SSMS it generates a script like the following.
DECLARE #return_value int
EXEC #return_value = [dbo].[spTitle_GetTitleById]
#TitleId = 1
SELECT 'Return Value' = #return_value /*Message comes from here*/
If youi wanted to avoid that for some reason you would need to SET NOCOUNT ON in the outer batch. See SET NOCOUNT ON usage for some discussion about the merits of having this ON or OFF
Just another question, when will it be wise (in what scenarios) to use SET NOCOUNT OFF?
See What are the advantages and disadvantages of turning NOCOUNT off in SQL Server queries? For the benefits turning SET NOCOUNT ON
As for why you would want to turn this off (so that rowcounts are returned) - you need this off whenever you want to be able to tell how many rows were affected in situations where there is no resultset, or you wish to be able to get a rowcount without first reading through the entire resultset.
For example in .Net the DataAdapter class uses rowcounts and so setting NOCOUNT ON causes issues when editing or deleting data (source).
That is not correct, script out the proc an make sure it is not OFF instead o ON, if it is ON it should not return (1 row(s) affected) messages
Also how are you executing the proc
is is just this
exec spTitle_GetTitleById 1
I have a problem with my script SQL, please help me.
Ex:
I have a insert statments:
INSERT INTO CUSTOMER (Code, Date) VALUES (1, GETDATE());
When I execute this insert, retuns the follow message:
"Msg 1934, Level 16, State 1, Server
HENRIQUE-PC, Line 5 INSERT 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 notificatio ns
and/or XML data type methods and/or
spatial index operations.".
Now, when I used SET QUOTED_IDENTIFIER ON, my insert is executed with success.
Ex:
SET QUOTED_IDENTIFIER OFF
GO
INSERT INTO CUSTOMER (Code, Date) VALUES (1, GETDATE());
SET QUOTED_IDENTIFIER ON
GO
(1 row(s) affected)
What relationship betwhen GETDATE() and QUOTED IDENTIFIER?
Why I need to use QUOTED IDENTIFIER in this case?
I believe it is because of getdate. Why?
Thanks.
Henrique Melicio
Henrique,
The reason you're getting that error is not related to GETDATE(), it has to do with indexes on columns from your CUSTOMER table. This bit from SQL Server 2008's SET Statements (Transact-SQL) document explains the issue in more detail:
When you are creating and manipulating
indexes on computed columns or indexed
views, the SET options ARITHABORT,
CONCAT_NULL_YIELDS_NULL,
QUOTED_IDENTIFIER, ANSI_NULLS,
ANSI_PADDING, and ANSI_WARNINGS must
be set to ON. The option
NUMERIC_ROUNDABORT must be set to OFF.
If any one of these options is not set
to the required values, INSERT,
UPDATE, DELETE, DBCC CHECKDB and DBCC
CHECKTABLE actions on indexed views or
tables with indexes on computed
columns will fail. SQL Server will
raise an error listing all the options
that are incorrectly set. Also, SQL
Server will process SELECT statements
on these tables or indexed views as if
the indexes on computed columns or on
the views do not exist.
I've seen many questions regarding the ANSI related settings,
and read some docs that state some features (like indexes on computed
columns and indexed views) can become worthless depending on
ANSI settings on or off...
So, what the recommended values for those:
ANSI_Padding
ANSI_NULLS
ANSI_WARNINGS
Concat_NULL_YELDS_NULL
QUOTED_IDENTIFIER
ARITHABORT
NUMERIC_ROUNDABORT
I would like guidelines regarding those.
For indexed views and indexed or persisted computed columns the following SET OPTIONS are all prescribed
SET options Required value
--------------------- -------------
ANSI_NULLS ON
ANSI_PADDING ON
ANSI_WARNINGS* ON
ARITHABORT ON
CONCAT_NULL_YIELDS_NULL ON
NUMERIC_ROUNDABORT OFF
QUOTED_IDENTIFIER ON
In SQL Server 2005 setting ANSI_WARNINGS to ON implicitly sets ARITHABORT to ON unless the database compatibility level is set to 80 or earlier (when it needs to be set explicitly).
Despite this it does make sense to be consistent in the ARITHABORT setting as this is used as a plan cache key and inconsistency can lead to duplicated plans wasting valuable plan cache space. You can see this from the query below.
SET ARITHABORT OFF
GO
SELECT * FROM master..spt_values WHERE number= -10 /*plan_cache_test*/
GO
SET ARITHABORT ON
GO
SELECT * FROM master..spt_values WHERE number= -10 /*plan_cache_test*/
GO
SELECT *
FROM sys.dm_exec_cached_plans
CROSS APPLY sys.dm_exec_plan_attributes(plan_handle) AS epa
CROSS APPLY sys.dm_exec_query_plan(plan_handle)
CROSS APPLY sys.dm_exec_sql_text(plan_handle)
WHERE attribute = 'set_options' AND text LIKE '%plan_cache_test%'
AND text NOT LIKE '%this_query%'
Even without the indexed view / persisted column requirements the OFF settings are deprecated for the following optionsANSI_PADDING,ANSI_NULLS,CONCAT_NULL_YIELDS_NULL and XQuery and XML data modification statements requires that QUOTED_IDENTIFIER be ON.