Best ANSI options when creating a new database

Question

I'm in the process of creating a new database onto SQL Server 2012 for our production environment. When I use the "New Database..." option from SQL Server Management Studio and generate the output I get:

CREATE DATABASE [AAA]
 CONTAINMENT = NONE
 ON  PRIMARY 
( NAME = N'AAA', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014\MSSQL\DATA\AAA.mdf' , SIZE = 5120KB , FILEGROWTH = 1024KB )
 LOG ON 
( NAME = N'AAA_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014\MSSQL\DATA\AAA_log.ldf' , SIZE = 1024KB , FILEGROWTH = 10%)
GO
ALTER DATABASE [AAA] SET COMPATIBILITY_LEVEL = 120
GO
ALTER DATABASE [AAA] SET ANSI_NULL_DEFAULT OFF 
GO
ALTER DATABASE [AAA] SET ANSI_NULLS OFF 
GO
ALTER DATABASE [AAA] SET ANSI_PADDING OFF 
GO
ALTER DATABASE [AAA] SET ANSI_WARNINGS OFF 
GO
ALTER DATABASE [AAA] SET ARITHABORT OFF 
GO
ALTER DATABASE [AAA] SET AUTO_CLOSE OFF 
GO
ALTER DATABASE [AAA] SET AUTO_SHRINK OFF 
GO
ALTER DATABASE [AAA] SET AUTO_CREATE_STATISTICS ON(INCREMENTAL = OFF)
GO
ALTER DATABASE [AAA] SET AUTO_UPDATE_STATISTICS ON 
GO
ALTER DATABASE [AAA] SET CURSOR_CLOSE_ON_COMMIT OFF 
GO
ALTER DATABASE [AAA] SET CURSOR_DEFAULT  GLOBAL 
GO
ALTER DATABASE [AAA] SET CONCAT_NULL_YIELDS_NULL OFF 
GO
ALTER DATABASE [AAA] SET NUMERIC_ROUNDABORT OFF 
GO
ALTER DATABASE [AAA] SET QUOTED_IDENTIFIER OFF 
GO
ALTER DATABASE [AAA] SET RECURSIVE_TRIGGERS OFF 
GO
ALTER DATABASE [AAA] SET  DISABLE_BROKER 
GO
ALTER DATABASE [AAA] SET AUTO_UPDATE_STATISTICS_ASYNC OFF 
GO
ALTER DATABASE [AAA] SET DATE_CORRELATION_OPTIMIZATION OFF 
GO
ALTER DATABASE [AAA] SET PARAMETERIZATION SIMPLE 
GO
ALTER DATABASE [AAA] SET READ_COMMITTED_SNAPSHOT OFF 
GO
ALTER DATABASE [AAA] SET  READ_WRITE 
GO
ALTER DATABASE [AAA] SET RECOVERY SIMPLE 
GO
ALTER DATABASE [AAA] SET  MULTI_USER 
GO
ALTER DATABASE [AAA] SET PAGE_VERIFY CHECKSUM  
GO
ALTER DATABASE [AAA] SET TARGET_RECOVERY_TIME = 0 SECONDS 
GO
ALTER DATABASE [AAA] SET DELAYED_DURABILITY = DISABLED 
GO
USE [AAA]
GO
IF NOT EXISTS (SELECT name FROM sys.filegroups WHERE is_default=1 AND name = N'PRIMARY') ALTER DATABASE [AAA] MODIFY FILEGROUP [PRIMARY] DEFAULT
GO

Why are so many ANSI options defaulting to OFF? The server instance was set up by RackSpace on our behalf. Could it be because of some defaults they set up in the instance?

Thanks, Chris

Answer 1

The options are defaulting to OFF because, in all likelihood, this database was created and scripted without touching any of the defaults. When a database is created, it is essentially cloned from the model system database, and on a brand new install of SQL Server the ANSI settings on the database will be OFF, even though some of these settings (like ANSI_NULLS) are options you would really never want to be OFF for any modern database application. In fact, in the case of ANSI_NULLS in particular, the documentation specifies that the ability to turn it off at all is deprecated, although it will likely still be a few years before that's really the case.

And therein lies the rub: these settings are still kept OFF for the benefit of old applications, who had to turn these options ON way back when to benefit from their goodness (and breaking changes). If the session specifies no values for them, the database settings are applied.

But most applications do specify these settings in a session, if not explicitly, then implicitly through their data access library. Per the documentation on SET ANSI_DEFAULTS, which toggles a bunch of settings at once:

The SQL Server Native Client ODBC driver and SQL Server Native Client OLE DB Provider for SQL Server automatically set ANSI_DEFAULTS to ON when connecting. The driver and Provider then set CURSOR_CLOSE_ON_COMMIT and IMPLICIT_TRANSACTIONS to OFF. The OFF settings for SET CURSOR_CLOSE_ON_COMMIT and SET IMPLICIT_TRANSACTIONS can be configured in ODBC data sources, in ODBC connection attributes, or in OLE DB connection properties that are set in the application before connecting to SQL Server. The default for SET ANSI_DEFAULTS is OFF for connections from DB-Library applications.

DB-Library is an old access library that is nevertheless still used by some ancient applications and optionally as a backing source for things like FreeTDS, so every so often you can still run into an application that deliberately or accidentally uses the database settings, but this is increasingly rare.

As to the best value for these options, that depends entirely on your use case. If you must support old applications that expect old behavior, you may have no choice in having to leave the database settings on OFF. If you have an application that connects through an old library but really expects modern SQL semantics, you may want to turn them ON. For all other applications, these options are likely already set on a per-session basis to their (in)correct values by the application itself and what you configure won't matter anyway.

A discussion on each individual option and when you'd want to turn it ON or OFF would exceed the limits of a reasonable answer. Consult the documentation on each of them and formulate your own best practices. You can let things like the SET option requirements for indexes on computed columns guide you, which require a bunch of options to be ON before you can even create them (and they're generally considered a nice thing to have).