Indstillingerne er som standard OFF fordi denne database efter al sandsynlighed blev oprettet og scriptet uden at berøre nogen af standardindstillingerne. Når en database oprettes, er den i det væsentlige klonet fra model systemdatabase, og på en helt ny installation af SQL Server vil ANSI-indstillingerne på databasen være OFF , selvom nogle af disse indstillinger (såsom ANSI_NULLS ) er muligheder, du virkelig aldrig ville ønske skal være OFF til enhver moderne databaseapplikation. Faktisk i tilfælde af ANSI_NULLS Specielt specificerer dokumentationen, at muligheden for overhovedet at slå det fra er forældet
, selvom der sandsynligvis stadig vil gå et par år, før det virkelig er tilfældet.
Og deri ligger problemet:Disse indstillinger holdes stadig OFF til fordel for gamle applikationer, som måtte slå disse muligheder ON langt tilbage, hvornår man kan drage fordel af deres godhed (og bryde ændringer). Hvis sessionen ikke angiver nogen værdier for dem, anvendes databaseindstillingerne.
Men de fleste programmer gør angiv disse indstillinger i en session, hvis ikke eksplicit, så implicit gennem deres dataadgangsbibliotek. I henhold til dokumentationen på SET ANSI_DEFAULTS
, som skifter en masse indstillinger på én gang:
DB-Library er et gammelt adgangsbibliotek, som ikke desto mindre stadig bruges af nogle ældgamle applikationer og eventuelt som en backing-kilde til ting som FreeTDS, så en gang imellem kan du stadig løbe ind i et program, der bevidst eller ved et uheld bruger databaseindstillingerne, men dette er mere og mere sjældent.
Hvad angår det bedste værdien for disse muligheder, det afhænger helt af din brugssituation. Hvis du skal understøtte gamle applikationer, der forventer gammel adfærd, har du muligvis ikke noget valg ved at lade databaseindstillingerne være OFF . Hvis du har et program, der opretter forbindelse gennem et gammelt bibliotek, men som virkelig forventer moderne SQL-semantik, kan det være en god idé at slå dem ON . For alle andre applikationer er disse muligheder sandsynligvis allerede indstillet på per-session-basis til deres (u)korrekte værdier af selve applikationen, og det, du konfigurerer, betyder alligevel ikke noget.
En diskussion om hver enkelt mulighed, og hvornår du ønsker at slå den ON eller OFF ville overskride grænserne for et rimeligt svar. Se dokumentationen om hver af dem og formuler din egen bedste praksis. Du kan lade ting som f.eks. SET valgmuligheder for indekser på beregnede kolonner
guide dig, som kræver en masse muligheder for at være ON før du overhovedet kan oprette dem (og de anses generelt for at være en god ting at have).