Cylance环境下MS Access数据库VBA代码遇运行时错误13求助

我之前在企业部署Cylance安全软件时，确实碰到过和你一模一样的问题——明明代码逻辑没问题，数据库也放进了白名单文件夹，却还是弹出错误13“类型不匹配”。分享几个我亲测有效的解决思路：

• 检查Cylance的脚本拦截日志与规则
  白名单文件夹只是允许数据库文件本身运行，但Cylance的Advanced Script Control模块可能还在拦截VBA里的特定操作（比如调用系统API、使用FileSystemObject、创建外部对象等）。你可以登录Cylance控制台，查看实时拦截事件，找有没有针对这个Access文件的VBA相关拦截记录，把对应的操作或对象添加到脚本控制的白名单规则里。

• 修复Access数据库的隐性损坏
  Cylance的后台拦截可能干扰了Access的正常读写，导致VBA项目出现隐性损坏（表面代码看起来正常，但运行时类型识别出错）。可以试试这几步：

  • 打开数据库时按住Shift键跳过自动运行，然后用「数据库工具」里的「压缩和修复数据库」功能；
  • 导出所有VBA模块到文本文件，新建空白Access数据库，再导入这些模块并重新关联表单/报表的代码；
  • 在VBA编辑器里执行调试→编译命令，有时候编译会定位到看似正常但实际有隐性问题的代码行，针对性调整。

• 调整Cylance对Office宏的信任策略
  即使数据库在白名单，Cylance可能还限制了Office宏的执行级别。在Cylance策略里找到Office相关规则，确保允许「受信任位置的宏」（如果你的白名单文件夹同时设置为Office受信任位置的话），或者适当放宽对信任文件夹内文件的宏代码扫描强度，关闭不必要的严格扫描选项。

• 拆分代码定位冲突点
  把报错的代码拆成最小可复现的片段，比如单独提取报错的函数到空白模块运行。如果单独运行不报错，说明是原数据库其他部分和Cylance有冲突；如果还是报错，大概率是这个函数里的某个操作被拦截（比如CreateObject("Scripting.FileSystemObject")），可以尝试用Access内置功能替代，比如用Dir、Kill等原生文件操作代替FSO。

• 联系Cylance技术支持
  如果以上方法都无效，把脱敏后的错误日志、代码片段提交给Cylance支持团队。他们可能有针对Access VBA的已知兼容补丁，或者能帮你调整更精准的策略规则。

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