我们有一个Access数据库拆分的前端/后端，它经常损坏（由于各种原因；不良的体系结构，不良的代码，过多的用户，缓慢的网络等等，我们目前正在SQL Server中进行重写） 。通常，发生这种情况时，管理员会通过电子邮件向所有员工发送电子邮件，并要求他们退出前端以及链接到后端的任何其他文件（例如，Excel中的某些报告已与其连接），因此我们可以打开数据库并使其自动压缩/当检测到其损坏状态时进行修复。
将用户带出系统就像放牧猫一样，我们并不总是能够及时地做到这一点。我已经实现了一个表单计时器事件，该事件检查第3个DB是否应保持打开状态的标志，其思想是在需要关闭前端时将标志设置为false。这似乎是有效的，但我无法确定它是否可以在100％的安装中正常运行，因为有时我们仍然会遇到该文件被锁定的情况。这可能是由于Excel报告，尽管很少查看。
最近，我不是在等待人们退出，而是在打开损坏的数据库之前先制作了一个副本，修复了副本，然后在修复完成后用复制的文件覆盖了原始数据库。这似乎运作良好。
我的问题是：覆盖后端有什么问题（如果有）？它会引起任何无法立即发现的问题吗？我已经做了几个星期了，还没有发现任何问题，但这只是一种不好的做法。例如锁定文件会怎样？会自动更新吗？
答案 0 :(得分：2)
不多，因为最坏的情况已经发生。
复制开放式Access数据库时，存在开放式事务和写入未完成，损坏数据库，未提交或破坏数据库的VB项目部分的风险。
但是，该文件已经损坏，并且如果您有未清事务，则在关闭文件时，会收到一条错误消息（这也是表单计时器不起作用的合理原因）。
我没有统计信息，但我认为通过向其写入事务来关闭损坏的数据库可能比仅通过开放事务复制它更危险，因为这些写入操作可能会覆盖本不应该的内容。
当然，当数据库没有损坏时，绝对不要这样做，因为如果数据库尚未损坏，它会导致损坏。
当然，如果您有间歇性的损坏，那么真正的问题应该是防止这种情况的发生，并且注释（this one）中提到的错误Gord Thompson非常普遍，很可能是罪魁祸首。它可以连续运行20次，直到一次出错，然后您必须恢复到备份，这可能会丢失数据（或更糟糕的是，没有备份并丢失更多数据）。