嘿，这个问题其实是64位Windows和Office架构里的常见痛点——先给你明确个核心事实：64位进程根本没法直接加载32位控件，这是内存寻址、指令集层面的硬限制，你之前在syswow64里注册32位OCX没用，就是因为64位Access根本不会去读32位的注册表分支。不过有几个可行的替代方案，我按优先级给你梳理下：

1. 优先找控件的64位官方版本 #

这是最省心也最稳定的方案：

• 直接联系OCX控件的开发商，问他们有没有适配64位的版本。现在很多常用的商业控件（比如报表、UI类）都已经更新了64位版本，哪怕是一些老控件，说不定也有后续的替代产品。
• 如果是微软自家的旧控件（比如MSFlexGrid、MSChart这类），可以换成Access内置的现代控件，或者用.NET的兼容组件来替代。

2. 试试COM代理进程（COM Surrogate） #

Windows的COM Surrogate机制能让64位程序间接调用32位COM组件，不过需要手动配置：

• 第一步先确保32位OCX注册正确：打开32位命令提示符（路径是C:\Windows\SysWOW64\cmd.exe），运行命令：regsvr32 "C:\你的控件路径\目标控件.ocx"
• 然后配置代理：
  1. 打开注册表编辑器（运行regedit），在32位注册表分支HKEY_CLASSES_ROOT\CLSID里搜索你的控件名称，找到它对应的CLSID（一串类似{XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}的字符串）。
  2. 在这个CLSID的项里，新建一个字符串值AppID，值设为一个新的GUID（可以用系统自带的guidgen.exe生成）。
  3. 接着在HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID下创建这个GUID对应的项，新建一个字符串值DllSurrogate，值留空就行。
• 注意：这个方法不是万能的，那些需要和Access进程直接共享内存、频繁交互的控件可能会出现兼容性问题，得自己测试。

3. 把32位控件封装成独立进程 #

如果上面的方法都不行，可以把32位OCX包成一个独立的32位服务或EXE，然后用进程间通信让64位Access和它交互：

• 比如用Visual Studio做一个32位的.NET程序，引用这个OCX控件，然后暴露一些简单的接口供外部调用。
• 64位Access里的VBA代码就可以通过COM或者管道通信，间接调用控件的功能。这个方法复杂度高，但可控性强，适合必须用这个控件的场景。

4. 折中方案：继续用32位Access #

如果以上方法都不现实，最省事的就是继续用32位版本的Access：

• 现在64位Windows完全兼容32位Office，只要你的数据库没用到64位专属的功能（比如超大内存寻址），32位Access运行起来和64位没什么区别，还能直接沿用原来的所有控件和加载项。
• 这个方案不需要做任何代码或配置修改，直接复用现有环境就行。

额外提醒：如果你的数据库VBA里调用了32位的Windows API，那就算用32位Access没问题，但如果以后真要转64位，得把这些API声明改成64位兼容的——比如加上PtrSafe关键字，调整Long类型为LongPtr之类的，不过这和OCX的问题是分开的。

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