ansi_nulls: 一些检查方法似乎不起作用

ansi_nulls: some ways to check it don't seem to work

documentation 声明数据库 ANSI_NULLS 标志在某些方面控制与 null 比较的行为。

我正在检查 this stack overflow post 以检查如何确定(未设置)此标志的值。有趣的是,并非所有答案似乎都适合我。

我的测试查询:

create table x(id int,txt nvarchar(max))
insert x(id,txt) values (1,'not null here'),(2,null)
select * from x

--query 1
select * from x where txt=null

--query 2
select * from x where txt<>null

返回的输出是两个空结果集。由此,我可以从逻辑上推断出 ANSI_NULLS 在我的数据库中处于开启状态。

现在,检查选项:

1

select databasepropertyex('MyDatabaseName', 'IsAnsiNullsEnabled')

Returns0.没想到会这样

2

DECLARE @options INT
SELECT @options = @@OPTIONS
IF ( (32 & @options) = 32 ) PRINT 'ANSI_NULLS'

打印“ANSI_NULLS”。预期。

3

SELECT is_ansi_nulls_on FROM sys.databases WHERE name = 'MyDatabaseName'

Returns0.没想到会这样

4

dbcc useroptions

结果集包含 [Set Option]='ansi_nulls' 和 [Value]='Set' 的行。预期。


为什么选项 1 和 3 给我这个结果?

我的@@版本是:

Microsoft SQL Server 2017 (RTM-GDR) (KB4505224) - 14.0.2027.2 (X64) 
    Jun 15 2019 00:26:19 
    Copyright (C) 2017 Microsoft Corporation
    Developer Edition (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: ) (Hypervisor)

您的查询涉及两个不同的事物。

一个是数据库默认值(可以使用 ALTER DATABASE SET 更改)- 另一个是在当前会话中设置的值。

数据库默认值几乎没有用,因为所有 ways of connecting to SQL Server set ANSI_NULLS on as described below

Connection-level settings that are set by using the SET statement override the default database setting for ANSI_NULLS. ODBC and OLE DB clients issue a connection-level SET statement setting ANSI_NULLS to ON for the session, by default. The clients run the statement when you connect to an instance of SQL Server. For more information, see SET ANSI_NULLS.

会话:

set ansi_nulls on;

select sessionproperty('ANSI_NULLS');

select ansi_nulls
from sys.dm_exec_sessions
where session_id = @@spid;

select case when null=null then 0 else 1 end;
-------------
set ansi_nulls off;

select sessionproperty('ANSI_NULLS');

select ansi_nulls
from sys.dm_exec_sessions
where session_id = @@spid;

select case when null=null then 0 else 1 end;