无法消除访问损坏答案

【问题标题】：Can't eliminate Access corruption无法消除访问损坏
【发布时间】：2013-08-20 18:20:24
【问题描述】：

我公司的 Access 数据库最近出现了一些严重的问题。我们得到的错误似乎表明它们已损坏 - 以下是最常见的：

访问文件时出错。网络连接可能已丢失。
编译此函数时出错。
没有错误，Access 完全崩溃了。

我注意到这些错误只发生在已编译的数据库中。如果我反编译它，它工作正常。如果我使用未编译的数据库并对其进行编译，它可以正常工作——直到我下次尝试打开它。看来将数据库编译成 .ACCDE 文件可以解决问题，这是我一直在做的，但有人报告说问题返回给她，这让我很紧张。

我尝试将数据库中的所有对象都导出为文本，从一个全新的数据库开始，然后再次将它们全部导入，但这并不能解决问题。将所有对象导入干净的数据库后，问题又回来了。

最后一点似乎是相关的，但我不明白如何。问题开始于我在数据库中添加一些类模块的时候。这些类模块使用 VBA Implements 关键字，通过引入一些多态性来清理我的代码。我不知道为什么这会导致问题，但时间似乎表明存在关系。

我一直在寻找解释，但还没有找到。有人有什么建议吗？

编辑：除了标准参考资料之外，该数据库还包括一些参考资料：

Microsoft ActiveX 数据对象 2.8
Microsoft Office 12.0
Microsoft 脚本运行时
Microsoft VBScript 正则表达式 5.5

【问题讨论】：

@HansUp 是的，我愿意。好点——我会编辑帖子。
@HansUp 每个人都使用 Access 2007。用户从网络获取自己的数据库副本，数据位于指向 SQL Server 的链接表中。
我假设数据库被拆分，前端被复制到每个客户端，后端在共享文件夹上？
@iDevlop 没错。
@HansUp 缺少参考不是问题。我可以在我自己的计算机上复制这个问题，参考绝对不是问题。

标签： vba ms-access ms-access-2007

【解决方案1】：

我在调试 Access 时所做和使用的一些事情：

在多个 VM 中测试我的应用程序。您可以在 Win8 上使用 HyperV、VMWare 或 VirtualBox 来设置各种受控测试环境，例如在 WinXP、Win7、Win8、32 位或 64 位上进行测试，只要符合您的操作系统范围和位数用户。
我使用vbWatchDog，这是一个聪明的实用程序，它只向您的应用程序添加几个类（没有外部依赖项），并允许您在高级别的地方捕获错误，并准确显示错误发生的位置。这对于捕捉和记录奇怪的错误非常宝贵，尤其是在现场。
如果问题仅出现在一个或几个用户身上，我会尝试找出他们的配置有什么特别之处。如果没有任何不妥之处，我将完全卸载所有 Office 组件并在清理注册表以查找悬空键并从旧安装中删除所有文件夹痕迹后重新安装它。
如果您的用户不需要完整版本的 Access，只需在他们的计算机上使用免费的 Access Runtime。
确保您始终使用一致的 Access 版本：如果您使用 Access 2007，请确保您的开发计算机也在使用该版本，并且所有其他用户也仅使用该版本并且没有组件从 Access 2010/2013 开始。
尝试确定崩溃是否总是围绕相同的用户操作发生。我使用一个简单的日志文件，在设置调试标志时写入该文件。日志文件是一个简单的文本文件，我每次记录某些内容时都会打开/写入/关闭它（我不会保持打开状态以确保将数据刷新到文件中，否则当 Access 崩溃时，您可能只有旧数据在日志文件中，因为新文件可能仍在缓冲区中）。例如，我记录的内容包括敏感函数的进入/退出、我从代码中执行的 SQL 查询、表单打开/关闭等。
一般来说，请确保您的应用程序编译没有问题（我的意思是从 IDE 执行调试 > 编译时）。这个阶段的任何问题都必须解决。
确保关闭所有打开的记录集，最好将它们的变量设置为Nothing。 VBA 不像以前对悬空引用那么敏感，但我发现它是一种很好的做法，尤其是当您不能绝对确定这些引用是否会被释放时（尤其是在模块级别或类级别执行操作时，例如，范围可能比预期的更长）。
同样，请确保正确销毁您在类中创建的任何 COM 对象（以及子/函数。Class_Terminate 析构函数必须明确清除所有对象。如果您创建了 COM 对象，这在关闭表单时也有效（你提到使用 ADOX、脚本对象和正则表达式）。一般来说，跟踪创建的对象是最重要的：确保通过重置它们显式释放所有对象（例如在字典上使用 RemoveAll，然后将它们的引用分配给 @ 987654329@。
不要过度使用On Error Resume 或On Error Goto。我几乎从不使用这些，除非绝对有必要从其他无法检测到的错误中恢复。使用这些错误捕获结构可以隐藏很多错误，否则这些错误会显示您的代码有问题。我更喜欢防御性编程而不是处理异常。
为了进行测试，请禁用错误捕获以查看它是否没有隐藏崩溃的原因。
确保前端在用户计算机上是本地的，您提到他们从网络获取各自的前端，但我不确定他们是从那里运行它还是复制它他们的本地机器。无论如何，它应该是本地的，而不是远程文件夹。
您提到使用 SQL Server 作为后端。尝试跟踪所有正在执行的查询。问题可能来自与 SQL Server 的通信、损坏的驱动程序、阻止某些查询运行的安全问题、返回意外数据的查询等。请密切关注服务器上的日志文件和事件日志以查找奇怪的错误，尤其是当它们涉及安全时。
说到事件日志，在你的用户的事件日志中寻找崩溃的痕迹。那里可能有信息，但很神秘。
如果您使用自定义功能区操作，请确保您不会导致问题。随着时间的推移，我在使用丝带时遇到了奇怪的问题。记录功能区进行的所有函数调用。

【讨论】：