Access 2016搭配SQL Server 2019用DAO更新记录时报运行时错误3197

错误本质 #

你遇到的3197报错并非真实存在其他用户锁定记录，是Access数据库引擎在执行更新前，对比记录集打开时缓存的字段值与表内实际值不匹配，主动触发的冲突拦截。几个现象可以直接佐证：

• 直接在表视图下修改问题记录时弹出"放弃更改/保存到剪贴板"的提示，这种弹窗是校验不通过的典型表现——真的行锁触发的提示是"记录正在被其他用户编辑"，和这个逻辑完全不同。
• 可以通过传递查询、Access查询设计器直接修改问题记录的任意值，这类操作绕过了Access客户端的缓存校验逻辑，直接让SQL Server执行更新，完全不受校验机制拦截。
• 已经确认的共享打开模式、无锁定设置、行级开关这些配置都不是问题来源，因为这些配置控制的是真实行锁逻辑，和当前的校验误判无关。

核心诱因定位 #

• datetime2(7)类型的RecordTimestamp字段是最大的问题源
  Access原生的DateTime类型仅支持精确到1/300秒的精度，根本无法存储datetime2(7)的7位毫秒精度值，读取这类字段时必然出现精度丢位，导致缓存的临时值和表内实际值不一致。同时这个字段的默认值仅在插入时由GetDate()生成，不会在行被更新时自动刷新值，只要表内的这个字段值被其他流程（SSMS手动修改、业务触发器、旧异常退出的会话残留改动）调整过，Access就会在更新校验时直接判定发生并发冲突。这也是为什么只有部分随机记录出问题：这些记录的精度丢位值、被后台修改的时间值刚好和Access缓存不匹配，大部分记录的值没出现偏移就可以正常更新。
• 缺乏SQL Server原生的并发检测专用字段
  Access在连接SQL Server表时，如果检测不到专门用于并发校验的rowversion字段，会默认把所有读到的字段都纳入更新校验范围，只要任何一个字段存在值偏移，就会拦截更新。你之前遇到的bit字段同类问题，本质也是bit字段在Access和SQL Server的隐式转换中出现值偏移（比如Access把bit的0存成-1），触发了同样的校验逻辑。
• 残留的对象引用导致的会话假锁
  你提供的测试代码中存在对象命名不匹配的问题：前面定义的记录集对象是productRS，后面关闭时写的是rs.close，这类错误会导致DAO对象没有被正常释放，残留的连接会话会持续持有旧的记录缓存，进一步放大校验不匹配的概率。

可直接落地的解决步骤 #

• 给SQL Server端的tblProducts表添加原生的rowversion类型字段，命名为RowVer，不需要设置任何默认值——SQL Server会自动在每次插入、更新行时为该字段生成全局唯一的递增二进制值。只要表中存在这个字段，Access会自动把并发校验逻辑从"比对所有字段"切换为"仅比对RowVer字段"，从根源上消除值不匹配的误判。
• 调整现有RecordTimestamp字段的配置：如果要保留这个字段记录创建时间，就把字段类型从datetime2(7)改为Access兼容的datetime(3)类型（仅保留3位毫秒精度），不要让它参与隐式的并发校验。对已经出现校验不匹配的问题记录，手动执行一次更新把RecordTimestamp值刷新为当前时间，即可解除当前的假冲突状态。
• 修正DAO记录集的打开逻辑：
  把原来的OpenRecordset语句补充上乐观锁参数，修改为：

  Set productRS = dbs.OpenRecordset("Select ProductID, Name, RowVer From tblProducts WHERE ProductID = " & ProductID, dbOpenDynaset, dbSeeChanges + dbOptimistic)
  

  同时修正代码中的对象命名不匹配问题，确保所有打开的记录集、数据库对象都被正确关闭和释放，避免残留会话。
• 不再使用Select *的方式打开用于更新的记录集，仅取出需要更新的业务字段、主键、RowVer字段，减少需要缓存比对的字段数量，进一步降低校验出错的概率。

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