Unable to Add Filtered Index but don't Understand Why - sql

I am trying to update a database from a database project in Visual Studio.
The update script is generated automatically. On line 133, the script adds a filtered index.
CREATE UNIQUE NONCLUSTERED INDEX [ProgramCodes_Value]
ON [dbo].[ProgramCodes]([Value] ASC) WHERE ([IsDeleted]=(0));
But this line produces some errors:
(133,1): SQL72014: .Net SqlClient Data Provider: Msg 1935, Level 16, State 1, Line 1 Cannot create index. Object 'ProgramCodes' was created with the following SET options off: 'ANSI_NULLS'.
(133,0): SQL72045: Script execution error. The executed script:
CREATE UNIQUE NONCLUSTERED INDEX [ProgramCodes_Value]
ON [dbo].[ProgramCodes]([Value] ASC) WHERE ([IsDeleted] = (0));
An error occurred while the batch was being executed.
First off, I really don't understand the ANSI_NULLS thing. Usually, this is just a harmless warning.
Second, I can see it failed when trying to add the filtered index, but I really can't see why. Checking the data, there are no duplicates that would violate this unique index.
Can anyone point me in the right direction to understanding the problem?

From the docs:
SET ANSI_NULLS must also be ON when you are creating or changing indexes on computed columns or indexed views. If SET ANSI_NULLS is OFF, any CREATE, UPDATE, INSERT, and DELETE statements on tables with indexes on computed columns or indexed views will fail. SQL Server will return an error that lists all SET options that violate the required values. Also, when you execute a SELECT statement, if SET ANSI_NULLS is OFF, SQL Server will ignore the index values on computed columns or views and resolve the select operation as if there were no such indexes on the tables or views.

Related

SQL Server FileTable Quoted Identifier error

I have a stored procedure that inserts BLOB (png images) into a SQL Server file table - like this:
...
INSERT INTO dbo.ImageContent ([name], file_stream)
VALUES ('example.png', BLOB);
...
When I execute the stored procedure, I get an error at the INSERT statement:
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 notifications and/or XML data type methods and/or spatial index operations.
The thing is the stored procedure does not involve any indexed views, computed columns, filtered indexes, query notifications, XML type or spatial indexes.
Does the SQL Server file stream technology (i.e. File Table in this case) need QUOTED_IDENTIFIER to be ON? Setting it ON resolves the issue, but I'm not sure why it needs that. The documentation does not say it is needed.
Any insight? Thanks.

Delete primary index of a database table programmatically

I need to delete a Primary key indexes on some database tables. Afterwards indexes will be re-created. Meanwhile some calculation will be performed.
I have following SQL Commands:
DROP INDEX "SAPSR3"."KNA1~0";
that are working correctly.
But once called within ABAP program:
EXEC SQL.
DROP INDEX SAPSR3.KNA1~0
ENDEXEC.
The message "SQL error 911 occurred when executing Native SQL" has been raised.
I've also tried with:
CALL FUNCTION 'RSDG_KEY_INDEX_DEL'
EXPORTING
i_tablnm = lv_tblname. " containing "KNA1"
This also doesn't work.
Is there any FM or similar way to perform such activity?
I also tried:
EXEC SQL.
DROP INDEX KNA1~0
ENDEXEC.
What you tried, in the SQL console (DROP INDEX "SAPSR3"."KNA1~0";), and in the ABAP program (DROP INDEX SAPSR3.KNA1~0), are not written identically as you can see!
I have just tried in ABAP below the version that you tried in the SQL console, and it dropped the index as intended!
EXEC SQL.
DROP INDEX "SAPSR3"."KNA1~0"
ENDEXEC.
So, why, in your ABAP attempt, did you remove the double quotes around the index name? (and also for the scheme name, but I guess it has less undesired effect).
In the SQL console, I'm really not sure that DROP INDEX SAPSR3.KNA1~0 works! Because there is the special "tilde" character, you need to add double quotes around the index name, the following is the minimal working syntax: DROP INDEX SAPSR3."KNA1~0".

cannot insert duplicate key row in table with unique index

I am debugging a stored procedure which gives me the following error when executed:
2601: Cannot insert duplicate key row in object 'dbo.TABLEXYZ' with unique index 'ABCKEY_PRIMARY'. The duplicate key value is (abc123).
There is no data being inserted in dbo.TABLEXYZ through the sproc I am executing, I also looked if there was any trigger which updated dbo.TABLEXYZ, but there was none. Any tips on how to approach debugging a complex sproc? Where else should I look to find the culprit?
It's likely the error happened in one of the sub-sprocs. Here's my approach:
Turn on the Execution Plan (Query menu > Include Actual Execution Plan)
Run the sproc. When it errors out, you will have an extra tab call Execution Plan
Scroll down to the last execution plan. Thạt's likely the statement that caused the error. The statement's text is provided.
Now scan your database to see where that statement is located.

SQLSERVER 2008 R2 Using filtered Indexes

Is it true, that QUOTED_IDENTIFIER is to be set to ON when using filtered Index ?
I know it has to be so when using indexed views or index on computed columns.
Yes - from the documentation:
Required SET Options for Filtered Indexes...
SET options Required value
QUOTED_IDENTIFIER ON
If the SET options are incorrect, the following conditions can occur:
The filtered index is not created.
The Database Engine generates an error and rolls back INSERT, UPDATE, DELETE, or MERGE statements that change data in the index.
Query optimizer does not consider the index in the execution plan for any Transact-SQL statements.

SQL 2005 Management Studio throwing syntax errors while trying to save changes to a table in Design view

Just recently, SQL 2005 Management Studio started throwing syntax errors while trying to save changes to tables. These are tables being made in Design view, not as TSQL scripts.
'Build_Group' table
- Unable to create index 'PK_Build_Group'.
Incorrect syntax near ','.
Based on the error, it seems that the recreation of the clustered index on the primary key is failing, but this is an entirely automated process by SQL, its own generated TSQL behind the scenes, and the change to the table was not to the key field, ie the clustered index that generated just fine before is now failing.
This install of SQL is more than a year old and I work in it every day with no problem. Nothing has changed to the environment that I know of.
Anyone seen this before ?
== EDIT TO ORIGINAL ==============================
Below is the Generated Change Script
BEGIN TRANSACTION
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON
SET NUMERIC_ROUNDABORT OFF
SET CONCAT_NULL_YIELDS_NULL ON
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
COMMIT
BEGIN TRANSACTION
GO
ALTER TABLE dbo.Build_Group ADD CONSTRAINT
PK_Build_Group PRIMARY KEY CLUSTERED
(
build_group_pk
) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
COMMIT
The syntax error is occurring on the WITH line. If I rem out the two ALLOW options, it will run.
here is my suggestion:
1) reboot your PC
2) enter SSMS
3) right click the table and select "refresh"
4) open the table, right click and select "Design", and make a change
5) click on the "generate change script" toolbar icon (or from the menu - "Table Designer" then "generate change script")
6) store a copy of this change script
7) attempt to save the table
8) if you still get an error, edit your question to include the change script
I have the same problem using SSMS v10 (SQL 2008) against an SQL Server 2000 server/database. If I create a table with a few columns in the designer and also set a primary key using the designer, then save and try Script table as > Create to > New query window it generates SQL with incorrect syntax.
Msg 170, Level 15, State 1, Line 58
Line 58: Incorrect syntax near '('.
Deleting the two ALLOW options didn't work for me, but removing the entire WITH clause does fix the issue. Regardless of whether this is the right thing to do, why does SMSS generate bad scripts?