我们有一个访问数据库，它位于共享文件夹中的服务器上。
几个月前，由于以下错误消息，数据库无法打开：
- 该文档在上次打开时导致了严重错误。
- Microsoft Access 检测到此数据库处于不一致状态，并将尝试恢复该数据库。
我能够通过从 Access 运行“压缩和修复”来解决这个问题，这似乎已经解决了它。
这个问题一直在发生，每次我运行相同的过程：
- 使用共享文件进入服务器并在计算机管理中关闭与文件和文件夹的所有“打开文件”连接。
- 打开数据库并运行“压缩和修复”
- 如果数据库创建了一个备份文件，通常称为“[原始文件名称]的备份”，请将其移至单独的文件夹以避免混淆打开哪个文件。
这个过程似乎每次都能解决问题，但我觉得不应该经常这样做。有时错误会在上次修复后几周发生，但有时会在我上次修复后的第二天发生。
我了解到的是多个人（通常一次最多 3-4 个）将同时访问这个数据库，对于那些经常使用它的人来说，整天打开它并不少见。有时我看到用户已经打开它好几天没有关闭它。
我能做些什么来防止这成为一个反复出现的问题吗？也许 Access 并不是真的要像这样使用？是否检查了数据库的更好的一致性/校验和以防止出现问题？
我已经研究过，这似乎是大海捞针，可能是任何数量的网络问题或其他事情。
希望我能引导您朝着正确的方向前进，因为您没有提供有关设置的信息（网络/Access 是如何设置的）：
Jet/ACE 数据库引擎默认是多用户的——它是从头开始构建的。所以可以排除原因
当网络处于标准级别时，共享 Jet/ACE 数据存储非常可靠。标准意味着 LAN over cable（不是 WAN / DialIn 和 NOT 无线，因为带宽必须足以让 Jet/ACE 维护 LDB 文件 - 用于多用户锁定）
数据库的正常使用意味着本地 PC 的 ping Jet/ACE 数据库引擎的实例每秒一次（使用默认设置），并且因为 Jet/ACE 无法从断开的连接中恢复（这可能是无线环境中的常见事件。 - 所以如果你现在有通过 WiFi 和之前在“有线”环境中的用户或那些“让访问权限开放数天”的用户是通过 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 来说不是问题），这应该没有问题。或者用 OPs 词来表达它
不可以排除这个。但是，如果使用 MAN/WAN 硬件元素（如 GSM/UMTS/LTE 连接器、空中 VPN、仅天线连接的网络部件或类似部件），这可能会导致问题 - 这里只有深入分析您的日志才能提供帮助或网络登录测试。您会在短时间内处理很多失败的 pings/重新发送数据包，这不是您在任何网络中遇到的偶尔错误的常见噪音，而是在 Access
The OP中工作时丢失/重置连接、重新连接到服务器等评论说一切都在一个大文件中（数据库和前端）。要解决这个问题，您必须拆分数据库。这是一个示例：如何拆分 Access 数据库