你的观察完全准确——Microsoft Access Database Engine 2016（ACE 2016）的SQL解析逻辑确实和ACE 2010存在差异，核心问题出在无对应位数Office/Access Runtime环境时，ACE 2016会强制启用更严格的ANSI-92 SQL模式，这直接导致了你遇到的查询失败问题。

具体原因拆解 #

1. LIKE语法失效问题 #

在ACE 2016中，当系统未安装同位数的Office或Access Runtime时，默认SQL模式会切换为严格ANSI-92兼容模式：

• 传统Jet/ACE引擎支持的LIKE '%somevalue%'语法会失效，必须使用ANSI标准的ALIKE '%somevalue%'；
• 而ACE 2010无论是否有Office环境，都默认保留了对Jet风格LIKE语法的兼容，所以你的旧查询能正常运行。

2. Yes/No字段判断异常问题 #

Access的Yes/No字段本质是布尔类型，在旧的Jet模式下可以用field <> 0这类数值判断逻辑。但在ACE 2016的严格ANSI模式下，必须使用布尔逻辑（比如field = True或field <> False），用数值比较会触发类型不匹配的异常。

为什么安装Access 2016 Runtime后恢复正常？ #

Access Runtime会加载完整的Access SQL解析环境，默认使用的是Access传统SQL模式（而非严格ANSI-92），因此你的旧查询语法能被正确识别执行。

可行解决方案（按推荐优先级排序） #

选项1：修改连接字符串强制兼容模式 #

无需改动SQL语句，只需在ADO连接字符串中添加扩展属性，强制ACE 2016使用传统Jet兼容模式。修改后的完整连接字符串示例：

Driver={Microsoft Access Driver (*.mdb)}; Dbq=MyDatabase.mdb; Mode=ReadWrite;Extended Properties="Jet OLEDB:Engine Type=5;ANSI=False;"

这个方案对现有代码侵入性最低，适合不想修改大量SQL语句的场景。

选项2：适配ANSI-92标准修改SQL语句 #

• 将所有LIKE '%somevalue%'替换为ALIKE '%somevalue%'；
• 将Yes/No字段的数值判断（如field <> 0）改为布尔逻辑判断（如field = True）。
  这种方案更符合现代SQL规范，能避免后续版本的兼容性问题，但需要梳理并修改代码中所有对应查询语句。

选项3：让客户安装ACE 2010 Redistributable #

如果你的应用不需要ACE 2016的新特性（比如支持更现代的Access数据库格式），这是最省心的选择——ACE 2010的SQL解析行为和你之前32位应用的环境完全一致，无需修改任何代码或配置，所有查询都能正常运行。

额外注意点 #

当主机安装了x64 Office时，ACE 2016会自动匹配Office的SQL模式，所以旧查询能正常运行，这也进一步验证了「SQL模式差异」是问题的核心。

内容的提问来源于stack exchange，提问作者Alastair Taylor