我们有一个 Access 数据库，位于服务器上的一个共享文件夹中。
几个月前，数据库因以下错误消息而无法打开：
- 该文档上次打开时发生严重错误。
- Microsoft Access 检测到该数据库处于不一致状态并将尝试恢复数据库。
我可以通过在 Access 中运行“压缩和修复”来修复该问题，而且似乎已经修复了它。
但该问题一直在发生，每次发生时我都会运行相同的程序：
- 进入具有共享文件的服务器，并在计算机管理中关闭与该文件和文件夹的所有“打开文件”连接。
- 打开数据库并运行“压缩和修复”
- 如果数据库创建了备份文件，通常称为“[原始文件名称] 的备份”，请将其移动到单独的文件夹，以避免混淆要打开哪个文件。
此过程似乎每次都能解决问题，但我觉得不必经常这样做。有时错误会在上次修复后几周发生，但有时这种情况发生在我上次修复后的第二天。
据我所知，多个人（通常最多 3-4 人同时访问该数据库）会同时访问，而且经常使用该数据库的人整天打开它的情况并不少见。有时我看到用户连续几天不关闭它。
我能做些什么来防止这个问题再次发生？也许 Access 并不是真正用来这样使用的？是否有更好的一致性/校验和检查来防止出现问题？
我已经研究过，似乎这就像大海捞针，可能是许多网络问题或其他问题。
答案1
希望我能为您指明正确的方向，因为您没有提供有关设置的信息（网络/如何设置 Access）：
Jet/ACE 数据库引擎默认是多用户的——它从一开始就是按照这种方式构建的。因此可以排除这是原因
当网络处于标准级别时，共享 Jet/ACE 数据存储非常可靠。标准意味着通过电缆使用 LAN（不是 WAN/DialIn，也不是无线，因为带宽必须足以让 Jet/ACE 维护 LDB 文件 - 用于多用户锁定）数据库
的正常使用意味着本地 PC 的 Jet/ACE 数据库引擎实例每秒 ping 一次（使用默认设置），并且因为 Jet/ACE 无法从断开的连接中恢复（这可能是无线环境中的常见事件。- 因此，如果您现在有通过 WiFi 的用户，而之前是在“有线”环境中，或者那些“让 Access 保持开放数天”的用户是通过 WiFi 的，您应该检查一下Access 出现“grandeza”问题的情况是共享前端 Access 应用程序 MDB 时。失败的原因在于您共享的内容无法可靠地共享，而且没有理由共享。由于 Access 对象存储在 MDB 文件中的方式（整个 Access 项目存储在其中一个系统表中的一个记录中的单个 BLOB 字段中），如果多个用户打开它，则很容易损坏。共享 Access 前端（或未拆分的 MDB，其中表和表单/报告/等都在一个 MDB 中）是 95% 的 Access/Jet/ACE 文件损坏的根源。- 如果是这种情况，您应该考虑重写应用程序的关键部分。
极少数情况下，安装新的防病毒软件或更新软件会导致服务器出现问题 - 这是由于锁定文件导致 JET/ACE 引擎运行混乱而导致的。幸运的是，通过查看服务器上的事件日志，可以轻松识别此问题，并从软件供应商处获取补丁，在几乎所有情况下都可以解决问题（当拥有排名前 10 的 AV-SW 时，很多公司都会受到影响，因此问题很快就会得到解决）
是的，我过去的一些客户在遇到情景 2 或 3 时总是争辩说“但到目前为止它一直有效”或“我们多年来一直都是这样做的”。我没有深入分析为什么从某个时间点开始（主要是由于添加表单/查询或更多用户使用 WiFi）它开始失败，而是删除了这个问题，从那时起一切都正常了。
编辑
OP 的网络正在覆盖一些楼层/建筑物。只要网络可靠（= 网络中的连接保持稳定 - 因此重新发送数据包对 Access 来说不是问题），这应该没有问题。或者用 OP 的话来说
“偶尔单次 ping 失败，这可能是问题所在”
不，这不能排除。但如果使用 MAN/WAN HW 元素（如 GSM/UMTS/LTE 连接器、无线 VPN、仅天线连接的网络部件或类似部件），这可能会导致问题 - 此时只有深入分析您的日志或进行登录网络测试才能有所帮助。您会在短时间内遇到大量失败的 ping/重新发送数据包，这不是任何网络中偶尔出现的错误，而是在使用 Access 时断开/重置连接、重新连接到服务器等。OP
评论说所有内容都在一个大文件中（数据库和前端）。要解决这个问题，您必须拆分数据库。这是一个示例：如何拆分 Access 数据库