我公司的Access数据库最近遇到了一些严重的问题。我们得到的错误似乎表明腐败 - 这是最常见的：
我注意到这些错误只发生在已编译的数据库中。如果我反编译它，它工作正常。如果我使用未编译的数据库并进行编译，它可以正常工作 - 直到下次我尝试打开它。似乎将数据库编译成.ACCDE文件解决了这个问题，这就是我一直在做的事情，但是有人报告说这个问题已经回归了，这让我很紧张。
我已经尝试将数据库中的所有对象导出到文本，从一个全新的数据库开始，然后再次导入它们，但这并不能解决问题。一旦我将所有对象导入到干净的数据库中，就会出现问题。
最后一点似乎是相关的，但我不明白如何。问题始于我将一些类模块添加到数据库的时候。这些类模块使用VBA Implements关键字，以通过引入一些多态来清理我的代码。我不知道为什么会导致这个问题，但时间似乎表明了这种关系。
我一直在寻找解释，但还没找到。有没有人有任何建议？
编辑：除标准数据库外，数据库还包括一些参考文献：
答案 0 :(得分：3)
我在调试Access时所做的一些事情：
在多个VM中测试我的应用。您可以在Win8，HyperV或VMWare上使用VirtualBox来设置各种受控测试环境，例如在WinXP，Win7，Win8,32位或64位上进行测试，只需对齐范围内的任何内容操作系统和用户的位数。
我使用vbWatchDog，这是一个聪明的实用程序，只为您的应用程序添加一些类（没有外部依赖），并允许您在高级别捕获错误，并向您显示它们发生的确切位置。这对于捕获和记录奇怪的错误是非常宝贵的，特别是在现场。
如果问题仅与一个或几个用户隔离，我会尝试找出有关其配置的特殊内容。如果没有任何不合适的地方，我会完全取消所有Office组件的保护，并在擦除注册表以获取悬挂键并从旧安装中删除所有文件夹痕迹后重新安装它。
如果您的用户不需要完整版本的Access，只需使用其计算机上的免费Access Runtime即可。
确保您始终使用Access的一致版本：如果您使用的是Access 2007，请确保您的开发计算机也在使用该版本，并且所有其他用户也只使用该版本且没有组件来自Access 2010/2013的信息。
尝试确定崩溃是否始终围绕相同的用户操作发生。我使用一个简单的日志文件，我在设置调试标志时写入。日志文件是一个简单的文本文件，我每次登录时都会打开/写入/关闭（我不打开它以确保将数据刷新到文件中，否则当Access崩溃时，您可能只有旧数据在日志文件中，因为新文件可能仍在缓冲区中）。我记录的东西，例如，敏感函数进入/退出，我从代码执行的SQL查询，表单打开/关闭等。
作为一般性，请确保您的应用程序编译没有问题（我的意思是在进行调试＆gt;从IDE编译时）。在这个阶段的任何问题都必须解决。
确保关闭所有打开的记录集，最好将其变量设置为Nothing。 VBA并不像过去那样敏感，但我发现这是一种很好的做法，特别是当你不能完全确定这些引用会被释放时（特别是当你在模块级或类级别进行操作时）范围可能比预期寿命长。）
同样，请确保正确销毁在类（和子/函数）中创建的任何COM对象。Class_Terminate析构函数必须明确清除所有。如果您创建了关闭表单，这也是有效的COM对象（您提到过使用ADOX，脚本对象和正则表达式）。一般来说，跟踪创建的对象是最重要的：确保通过重置它们来明确释放所有对象（例如在字典上使用RemoveAll，然后分配他们对Nothing。
请勿过度使用On Error Resume或On Error Goto。我几乎从不使用这些，除非绝对有必要从其他无法检测的错误中恢复。使用这些错误捕获构造可以隐藏许多错误，否则这些错误会向您显示代码出错。我更喜欢防御性地编程，而不是处理异常
要进行测试，请禁用错误捕获以查看它是否未隐藏崩溃的原因。
确保前端是用户计算机的本地，你提到他们从网络获得了他们各自的前端，但是我不确定他们是从那里运行它还是它复制了他们的本地机器。无论如何，它应该是本地的而不是远程文件夹。
您提到使用SQL Server作为后端。尝试跟踪正在执行的所有查询。问题可能来自与SQL Server的通信，损坏的驱动程序，阻止某些查询运行的安全问题，查询返回意外数据等。请密切关注服务器上的日志文件和事件日志以查找奇怪的错误，特别是如果他们涉及安全。
说到事件日志，请在用户的事件日志中查找崩溃的跟踪。那里可能有信息，无论多么神秘。
如果您使用自定义功能区操作，请确保不会导致问题。随着时间的推移，我发现了奇怪的问题。记录功能区所有的所有函数调用。