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?
Related
I cannot alter/drop any objects in my database, only create, insert, and delete records. For instance, I'm getting...
You can not
Msg 3609, Level 16, State 2, Line 1
The transaction ended in the trigger. The batch has been aborted.
on the following code (on the drop table step):
create schema Test
go
create table test.test (
test varchar(5)
)
go
insert into test.test(test) values('test')
go
select *
from Test.test
go
drop table Test.test
go
drop schema Test
go
I have definitely not created any triggers on the database EVER. I do not have control of the server so my permissions are limited. The problem just occurred. I have been using this database for years. This is the first time this has happened. I believe it has something to do with permissions.
I have no idea what is causing this new error to occur.
I found the problem. Someone hacked my database by adding a database trigger "test_ddl_trigger":
`SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
create trigger [test_ddl_trigger] on database for drop_table, alter_table as print 'You can not'
rollback
;
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
ENABLE TRIGGER [test_ddl_trigger] ON DATABASE
GO`
We're trying to diagnose some performance issues on both SQL Server 2008 and SQL Server 2008 R2 arising from bad query plans that get cached on behalf of users but are unable to exactly reproduce them in SSMS as we cannot convince SQL Server to match the application's set_options value of 255 that gets returned from sys.dm_exec_plan_attributes, aka. ##OPTIONS.
The ##OPTIONS bit mask is documented at the following MSDN page:
Configure the user options Server Configuration Option
According to the above page the following combination of SET statements should yield an ##OPTIONS value of 255:
SET DISABLE_DEF_CNST_CHK ON
SET IMPLICIT_TRANSACTIONS ON
SET CURSOR_CLOSE_ON_COMMIT ON
SET ANSI_WARNINGS ON
SET ANSI_PADDING ON
SET ANSI_NULLS ON
SET ARITHABORT ON
SET ARITHIGNORE ON
SET QUOTED_IDENTIFIER OFF
SET NOCOUNT OFF
SET ANSI_NULL_DFLT_ON OFF
SET ANSI_NULL_DFLT_OFF OFF
SET CONCAT_NULL_YIELDS_NULL OFF
SET NUMERIC_ROUNDABORT OFF
SET XACT_ABORT OFF
But when you exec that you get the warning:
Line 1: The option 'DISABLE_DEF_CNST_CHK' is obsolete and has no effect.
And PRINT ##OPTIONS returns 254 instead of 255.
Clearly Connection Pooling is able to sort this out when you see EXEC sp_reset_connection in SQL Profiler, as none of our application code actually changes any SET options. But of course we can't call sp_reset_connection from SSMS:
Msg 208, Level 16, State 9, Procedure sp_reset_connection, Line 1
Invalid object name 'sp_reset_connection'.
Is there a trick to get that last DISABLE_DEF_CNST_CHK bit into play? An alternative option name or a system table to tweak?
Well I've found one way to SET DISABLE_DEF_CNST_CHK ON but I DO NOT recommend doing this on a production server...
When new connections are established SQL Server sets ##OPTIONS to the value stored against the 'user options' row in the sys.configurations view. This value defaults to 0. You can check the configured and running value with:
select * from sys.configurations where name = 'user options'
-- or:
EXEC sp_configure 'user options'
As a user with the sysadmin or serveradmin role you can change the value for future connections with:
EXEC sp_configure 'user options', 1
GO
RECONFIGURE
GO
Note that changing this setting affects all future connections to the server which is why I DO NOT recommend doing this on a production server.
After changing this configuration value, then opening a new connection in SSMS, using the other SET options as described in the original question finally got us to ##OPTIONS 255.
I have a problem in my application while executing a SQL query. I attached SQL Profiler to see the problem.
A query like
SELECT abc_id
FROM abc_Master
WHERE abc_name = #abcName COLLATE SQL_Latin1_General_CP1_CS_AS
AND (status=''active'' OR status=''live'')
is taking 60.102 seconds to execute.
I have noticed an audit login log record above this query log in server profiler trace list.
-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
Is this causing the delay? why is the query taking 60 secs to execute?
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.
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.