3

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

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

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

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

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

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

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

  • Microsoft ActiveX 数据对象 2.8
  • 微软办公软件 12.0
  • Microsoft 脚本运行时
  • Microsoft VBScript 正则表达式 5.5
4

1 回答 1

3

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

  • 在多个 VM 中测试我的应用程序。您可以在 Win8、VMWare或VirtualBox上使用HyperV来设置各种受控测试环境，例如在 WinXP、Win7、Win8、32 位或 64 位上进行测试，只要与您的用户的操作系统范围和位数相匹配。

  • 我使用vbWatchDog，这是一个聪明的实用程序，它只向您的应用程序添加几个类（没有外部依赖项），并允许您在高级别的地方捕获错误，并准确地告诉您它们发生的位置。这对于捕捉和记录奇怪的错误非常宝贵，尤其是在现场。

  • 如果问题只出现在一个或几个用户身上，我会尝试找出他们的配置有什么特别之处。如果没有什么不妥之处，我将完全卸载所有 Office 组件并在清理注册表以查找悬空键并从旧安装中删除所有文件夹痕迹后重新安装它。

  • 如果您的用户不需要完整版本的 Access，只需在他们的计算机上使用免费的Access Runtime 。

  • 确保您始终使用一致的 Access 版本：如果您使用的是 Access 2007，请确保您的开发机器也在使用该版本，并且所有其他用户也仅使用该版本，并且 Access 2010/2013 中没有任何组件当下。

  • 尝试确定崩溃是否总是围绕相同的用户操作发生。我使用一个简单的日志文件，在设置调试标志时写入该文件。日志文件是一个简单的文本文件，我每次记录某些内容时都会打开/写入/关闭（我不会保持打开状态以确保数据已刷新到文件中，否则当 Access 崩溃时，您可能只有旧数据在日志文件中，因为新文件可能仍在缓冲区中）。例如，我记录的内容包括敏感函数进入/退出、我从代码执行的 SQL 查询、表单打开/关闭等。

  • 一般来说，确保您的应用程序编译没有问题（我的意思是在从 IDE 执行 Debug > Compile 时）。这个阶段的任何问题都必须解决。

  • 确保关闭所有打开的记录集，最好将它们的变量设置为Nothing. VBA 不像以前对悬空引用那么敏感，但我发现它是一种很好的做法，尤其是当您不能绝对确定这些引用是否会被释放时（尤其是在模块级别或类级别进行操作时，例如，范围可能比预期的寿命更长）。

  • 同样，请确保正确销毁您在类中创建的任何 COM 对象（以及子/函数。Class_Terminate析构函数必须显式清除所有对象。如果您创建了 COM 对象（您提到使用 ADOX、脚本对象和regex). 一般来说，跟踪创建的对象是最重要的：确保通过重置它们来明确释放所有对象（例如RemoveAll在字典上使用，然后将它们的引用分配给Nothing.

  • 不要过度使用On Error Resume或On Error Goto。我几乎从不使用这些，除非绝对有必要从其他无法检测到的错误中恢复。使用这些错误捕获结构可以隐藏许多错误，否则这些错误会显示您的代码有问题。我更喜欢防御性编程而不是处理异常。
    为了进行测试，请禁用错误捕获以查看它是否没有隐藏崩溃的原因。

  • 确保前端在用户机器上是本地的，你提到他们从网络上获得了他们自己的前端，但我不确定他们是从那里运行它还是复制到他们的本地机器上。无论如何，它应该是本地的而不是远程文件夹。

  • 您提到使用 SQL Server 作为后端。尝试跟踪所有正在执行的查询。问题可能来自与 SQL Server 的通信、损坏的驱动程序、阻止某些查询运行的安全问题、返回意外数据的查询等。请密切关注服务器上的日志文件和事件日志以查找奇怪的错误，特别是如果它们涉及安全。

  • 说到事件日志，请在用户的事件日志中查找崩溃的痕迹。那里可能有信息，但很神秘。

  • 如果您使用自定义功能区操作，请确保您不会导致问题。随着时间的推移，我在使用丝带时遇到了奇怪的问题。记录功能区进行的所有所有函数调用。

于 2013-08-21T01:35:20.293 回答