OLEDB连接向Access库执行参数化INSERT查询抛出“参数过少”异常

运行时抛出的OleDbException提示为：

Too few parameters. Expected 2

这是Access OleDb提供程序的典型解析错误，触发逻辑固定为：引擎对传入的SQL文本做预解析时，识别到的“需要外部传值的占位符总数”，与代码实际传递的参数数量存在差值，报错提示的数字就是两者的差值。 #

• 这套代码编写时适配的是Access Database Engine 2010的解析逻辑：该版本容错性极强，一方面严格遵循OleDb的位置参数匹配规则（不识别参数名、只按参数出现顺序绑定传值），另一方面能正确识别SQL文本内的硬编码布尔值、带方括号的特殊列名，不会将非占位符内容误判为需要传值的参数。代码在7年间稳定运行，本质是之前系统内的ACE引擎版本一直保持在兼容旧逻辑的状态。
• 近期系统通过Office365自动推送将引擎升级到最新的16.x分支后，解析规则存在非向后兼容的调整：
  • 预解析参数时，无法正确识别SQL文本中无类型标识的小写false为布尔常量，反而将其判定为未定义的参数占位符
  • 对带方括号的特殊列名做解析时，会在参数化查询的预校验阶段误触发参数校验逻辑
    最终引擎累计识别到4个需要传值的位置，而代码实际仅传递了2个参数，差值为2，刚好触发对应的报错提示。

当将所有值直接拼入SQL文本时，整个语句是完全由硬编码内容组成的完整可执行结构，引擎会跳过针对参数化查询的预校验环节，上述的误判逻辑不会被触发，因此可以正常执行。 #

• 安装旧版2010 Access Database Engine的解决方案完全有效，本质是将引擎解析逻辑回退到了和旧代码适配的兼容状态
• 若不想绑定旧版引擎，可直接修改现有代码适配新版引擎规则：
  • 将SQL语句中硬编码的false替换为Access明确识别的布尔值写法，比如直接写0代表“假”值
  • 保持参数添加顺序和SQL中值出现的顺序完全一致，这是OleDb适配Access的固有要求（不支持按参数名匹配）
  • 可移除参数名前的@前缀，OleDb本身不依赖参数名做匹配，去掉前缀能进一步降低新版引擎误判的概率

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