我们有一个Access数据库拆分的前端/后端，它经常损坏(由于各种原因：糟糕的体系结构、糟糕的代码、用户太多、网络速度慢等等，我们目前正在SQL Server中重写(。通常，当这种情况发生时，管理员会给所有员工发电子邮件，要求他们退出前端和链接到后端的任何其他文件(例如Excel中的一些报告与之相连(，这样我们就可以打开数据库，并在检测到数据库处于损坏状态时自动压缩/修复它。
让用户退出系统就像放羊一样，我们并不总是能够及时做到这一点。我已经实现了一个表单计时器事件，它检查第三个DB是否应该保持打开的标志，其想法是当我们需要关闭前端时，我们将该标志设置为false。这似乎很有效，但我不能确定它是否适用于100%的安装，因为有时我们仍然会遇到文件被锁定的情况。这可能是因为Excel报告，尽管这些报告很少被查看。
最近，我没有等待人们退出，而是在打开损坏的数据库之前复制它，修复副本，然后在修复完成后用复制的文件覆盖原始文件。这似乎很有效。
我的问题是：覆盖后端有什么问题(如果有的话(？它会引起任何不明显的问题吗？我已经做了几个星期了，没有注意到任何问题，但感觉这是一种糟糕的做法。锁定文件发生了什么？它会自动更新吗？
不多，因为最坏的情况已经发生了。
复制开放式Access数据库时，存在打开的事务和写入操作完成一半、损坏数据库、未提交或破坏数据库的VB Project部分的风险。
但是，文件已经损坏，如果你有一个打开的事务，在关闭它时，你会收到一条错误消息(这也是你的表单计时器不工作的可能原因(。
我没有统计数据，但我认为通过向已损坏的数据库写入事务来关闭数据库可能比用打开的事务复制数据库更危险，因为这些写入可能会覆盖不应该覆盖的内容。
当然，当数据库未损坏时，千万不要这样做，因为如果数据库尚未损坏，可能会导致损坏。
当然，如果你有间歇性的腐败，那么真正的问题应该是防止这种情况发生，而Gord Thompson在评论中提到的bug(这个(非常常见，很可能是罪魁祸首。它可以连续运行20次，直到出现一次错误，然后您将不得不恢复到备份，可能会丢失数据(或者更糟的是，没有备份，会丢失更多数据(。