我正在开发一个应用程序，它使用 MS Access 数据库（.mdb，不是我的决定）作为后端。最近我遇到有人建议在 WAN 上使用 JET 引擎并不是一个好主意，数据损坏的风险很高。由于我的应用程序应该这样做（连接到 NAS 上的数据库（编辑：不是 NAS，共享共享网络驱动器），我很担心。这真的有那么大的风险吗？如果是这样，是否有任何解决方法或者是 MS Access 数据库只是无法用于那种应用程序？
编辑
前端是 C# (WPF) 中的 .NET windows 桌面应用程序。系统没有很多用户，最多 10 个。大部分时间他们会从 LAN 访问数据库，并且 99% 的数据库写入将在 LAN 内完成（来自公司区域）。但是，在某些情况下，他们将通过网络（从他们的家中）从公司外部连接到 NAS（编辑：不是 NAS，共享共享网络驱动器）。
您描述的场景不适合将 Access 数据库作为后端。WAN 用户很可能会发现应用程序运行缓慢，但 NAS 才是真正需要担心损坏的原因，这会影响 LAN 和 WAN 用户。
许多（大多数？）NAS 设备在 Linux 上运行并使用 Samba 提供 Windows 文件共享服务。Access 数据库引擎显然使用了 Samba 并不总是完全实现的“真实”Windows 文件共享的一些低级功能（参考：此处）。
事实上，我唯一一次看到共享 Access 后端（以及正确分布的前端）反复出现损坏问题是当客户端将其文件共享从较旧的 Windows 服务器移动到较新的 NAS 设备时。Access 应用程序大部分时间都在继续工作，但每隔几个月他们就会发现，在对后端数据库文件进行压缩和修复后，某些表的主键会消失。当他们的文件共享位于 Windows 服务器上时，这种情况从未发生过。
如果你有一个 100 Mb/s 的光纤，那没问题，但如果你的线路是 xDSL 线路，那通常是绝对不行的。
说服将后端移动到像 SQL Server 这样的服务器引擎的权力，其中 Express 版本是免费的。
将前端与后端分离可以消除大部分腐败风险。当然，使用 Access 总是有可能的，如果您正在寻找将风险降低到接近零的东西，那么您可能需要考虑 SQL Server 或 MySQL。但是，只要您采取适当的预防措施，就可以使用 Access。
例如，您可能希望查看将被编辑的表的记录锁定，以防止多个同时写入。定期备份数据库也总是好的。