我组成一个由10名测试工程师组成的团队，他们全部在网络服务器上共享一个公共Access 2013数据库。每个人都具有对数据库的读/写访问权限。任何人都可以随机打开数据库，向数据库中写入数据，然后关闭数据库。这些动作都是通过Labview代码“向幕后”传递给用户的。即用户将在Labview中启动特定的测试，该代码（在开始测试之前）将打开共享的DB，将测试信息写入表格，然后在开始测试之前将其关闭。现在，我们有4个实例，有人会抱怨他们突然无法访问此共享数据库。经过调查，我们发现数据库某种程度上已经变成了只读文件，因此Labview写入该文件的尝试失败了。我的问题不是“如何使数据库再次读/写”（我在该主题上找到了其他帖子），而是为什么读/写数据库突然变成只读？我们试图追踪到失败的“关闭数据库”，但没有发现任何问题。每当这种情况发生时，都不会与数据库关联任何锁定（.lck）文件，因此它似乎没有被锁定。
有什么想法在这里发生什么事吗？
谢谢！
答案 0 :(得分：0)
不同的设施访问数据库文件的事实引起了有关可能的网络问题的更多危险信号。 不是基于文件的访问数据库是为可靠的WAN访问而设计的，因此许多人都不愿使用这种配置。
尽管您报告没有残留的锁定文件，但是* .ldb和* .laccdd文件仅用于数据库引擎的内部锁定算法。它与文件服务器的OS锁定机制结合使用。我怀疑您有一个数据库客户端，其OS文件锁未正确释放，因此该锁一直保持到超时。那将解释您关于即使在断开其他客户端连接后延迟锁定的观察。您提到重启客户端计算机，但是我怀疑重置主机文件服务器会立即释放锁定。
当然，在您的情况下，最好使用全新的基于服务器的解决方案，有可能产生一种中间解决方案，从而避免对LabView代码进行彻底检查。安装和设置SQL Server，然后将Access数据库表更改为将表链接到SQL后端。每个LabView客户端将有自己的Access DB副本链接到同一服务器。这是一个快速而肮脏的描述，可能不是理想的描述，但是它可以消除此特定问题。