Sunday, February 19, 2012

How to stop PAD_INDEX being scripted

Our team checks SQL scripts into version control. On my machine, however, the generated script always differs slightly. When I generate a create table script, the primary key part always has PAD_INDEX = OFF. Nobody else's server generates this. Does anyone know what option or setting I need to change to prevent PAD_INDEX = OFF from being output?

WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]

BOL specifies

When creating indexed views or manipulating rows in tables participating in an indexed view, seven SET options must be assigned specific values. The SET options ARITHABORT, CONCAT_NULL_YIELDS_NULL, QUOTED_IDENTIFIER, ANSI_NULLS, ANSI_PADDING, and ANSI_WARNINGS must be ON. The SET option NUMERIC_ROUNDABORT must be OFF.

If any of these settings is different, data modification statements (INSERT, UPDATE, DELETE) on any table referenced by an indexed view fail and SQL Server raises an error listing all SET options that violate setting requirements. In addition, for a SELECT statement that involves an indexed view, if the values of any of the SET options are not the required values, SQL Server processes the SELECT without considering the indexed view substitution. This ensures correctness of query result in cases where it can be affected by the above SET options.

If the application uses a DB-Library connection, all seven SET options on the server must be assigned the required values. (By default, OLE DB and ODBC connections have set all of the required SET options correctly, except for ARITHABORT.)

|||

Thank you for taking the time to copy and paste. However, I don't see how your post is relevant.

I am asking what determines whether the PAD_INDEX option is included in scripted CREATE TABLE statements.

|||Is anyone able to help with this?

No comments:

Post a Comment