为何SQL Server的bit列不将-1判定为True？Access联动查询异常求助

这个问题其实是SQL Server和Access在布尔类型底层实现、ODBC驱动映射，加上SQL Server隐式转换规则共同造成的，我来拆解清楚：

1. 先搞懂SQL Server的bit类型到底怎么回事 #

SQL Server的bit类型本质上只存两个值：0（对应False）和1（对应True）。不管你往这个列里插什么非0整数——包括-1——都会被自动转成1。

你在SSMS里用WHERE Column1 = -1能查到行，核心是SQL Server的隐式转换逻辑：当你用整数-1和bit列比较时，SQL Server会把-1转换成bit类型的1（因为所有非0值都会被转成1），所以这个条件其实等价于WHERE Column1 = 1，自然能匹配到所有True的行。

至于SSMS里显示-1，大概率是客户端显示的小问题——比如旧版本工具的默认显示、你不小心改了列的显示格式，或者用了转换函数时的误解？毕竟正经把bit列转成int的话，得到的只会是1，不可能是-1，你的bit列实际存储的还是1。

2. Access链接表的查询为什么不一样 #

Access的布尔类型是Yes/No，底层用整数存：Yes（True）对应-1，No（False）对应0——这是VBA语言的布尔值标准，和SQL Server完全不一样。

当Access通过ODBC链接SQL Server的bit列时，驱动会做双向映射：SQL Server的1变成Access的Yes（也就是-1），0变成No（0）。但查询时的逻辑就有区别了：

• 如果你在Access里写WHERE Column1 = -1，Access会把-1作为整数参数传给SQL Server。这时候SQL Server会按照数据类型优先级，把bit列转换成整数（也就是1），然后和-1比——1 = -1显然不成立，所以查不到行。
• 但如果你写WHERE Column1 = 1，SQL Server会把1转换成bit类型的1，和列里存的1匹配，自然就能返回正确的结果。

3. 更稳妥的跨平台查询方式 #

为了避免这种踩坑，建议不管在SSMS还是Access里，都用布尔字面量来查询，别用整数：

• 在SSMS里：直接写WHERE Column1（因为非0的bit值会被视为True），或者清晰点WHERE Column1 = 1，完全没必要用-1。
• 在Access里：对链接表查询时写WHERE Column1 = True——Access会自动把这个条件转换成SQL Server能理解的WHERE Column1 = 1，既符合Access的语法习惯，又不会出类型转换的问题。

内容的提问来源于stack exchange，提问作者Brian Battles