如何重写DLL已加载类的同名方法 消除名称歧义实现多数据库兼容

报错本质说明 #

你遇到的ambiguous name detected报错，核心原因是VBA项目在静态引用DAO360.dll类型库时，会把该库导出的所有全局对象、方法、类型名称全部加载到当前项目的全局符号表；当你自己编写的PostgreSQL适配类、自定义方法和这些DLL导出的名称完全重名时，编译器无法判定你要调用的是DLL原生逻辑还是你的自定义实现，就会直接抛出歧义报错。

具体解决操作 #

• 调整全局调用的命名前缀，缩小名称匹配范围
  打开VBA编辑器的「工具-引用」配置面板，将你的PostgreSQL适配类所在项目的引用优先级调整到DAO类型库上方；逐一排查项目中所有调用DAO原生功能的代码，把没有加库前缀的裸调用，比如DBEngine、OpenRecordset、Recordset这类声明，全部替换为带完整库前缀的写法：DAO.DBEngine、DAO.Database.OpenRecordset、DAO.Recordset。当所有DAO调用都强制绑定到DAO命名空间下时，自定义类里的同名方法就不会和DLL导出的原生名称产生匹配冲突。
• 做接口隔离设计，避免公开成员与DLL名称直接重名
  你最初设计的“针对不同数据源写专用实现类”的思路完全可行，不需要推翻，只需要调整类的公开成员命名：比如DAO原生有Execute方法，你在PostgreSQL适配类里不要把同名的公开方法直接命名为Execute，可以改名为ExecutePGQuery；再在适配层写一个统一的入口判断逻辑，根据当前实际连接的数据源类型分发调用——连Access数据源就调用DAO层的原生实现，连PostgreSQL就调用你自己写的PG适配逻辑。这种设计既保留了多数据库兼容的能力，又从公开接口层避开了和DLL导出名称的直接撞名，不会触发歧义检测。
• 改用动态绑定方式调用DAO组件，从根源避免命名空间污染
  静态引用DAO360.dll会把整个类型库的符号全部注入项目全局名称表，这是冲突的核心来源。你可以直接删掉项目中对DAO360.dll的静态引用，所有需要用到DAO功能的地方改用CreateObject("DAO.DBEngine.120")的方式动态实例化组件。因为动态绑定的对象不会在编译阶段把内部成员名加载到全局符号表，哪怕你写的自定义类、方法名和DAO内部的实现完全一致，编译器在编译期也感知不到这些DAO成员，自然不会触发歧义报错。
  注意：动态绑定DAO的时候，所有DAO相关的对象变量要统一声明为Object类型，不要提前声明具体的DAO类类型，否则静态类型检查还是会拉取DAO的类型信息，重新引入命名冲突。

内容的提问来源于stack exchange，提问作者Victor Melançon