首页 > 解决方案 > Access 2013 DB 神秘更改为只读

问题描述

我在一个由 10 名测试工程师组成的团队中工作,他们都在网络服务器上共享一个通用 Access 2013 数据库。每个人都具有对数据库的读/写访问权限。任何人都可以随机打开数据库,向其中写入数据,然后将其关闭。这些操作都是通过 Labview 代码“在幕后”向用户完成的。即用户将在 Labview 中启动特定测试,代码(在开始测试之前)打开共享数据库,将测试信息写入表,然后在开始测试之前将其关闭。我们现在有 4 个实例,有人会抱怨他们突然无法访问这个共享数据库。经过调查,我们发现数据库不知何故变成了一个只读文件,因此 Labview 对其写入的尝试失败了。我的问题不是“如何让数据库再次读/写”(我 已经找到关于该主题的其他帖子),但是为什么读/写数据库突然变成只读的?我们试图追查到失败的“关闭数据库”,但什么也没找到。每当发生这种情况时,都没有与数据库关联的锁定 (.lck) 文件,因此它似乎没有被锁定。

有什么想法可能在这里发生吗?

提前致谢!

标签: ms-accessms-access-2013labview

解决方案


不同设施访问数据库文件这一事实引发了更多关于可能的网络问题的危险信号。基于文件的 Access 数据库不是为可靠的 WAN 访问而设计的,许多人完全不鼓励这种配置。

尽管您报告没有残留锁定文件,但 *.ldb 和 *.laccdd 文件仅适用于数据库引擎的内部锁定算法。它与文件服务器的操作系统锁定机制一起工作。我怀疑您有一个数据库客户端,其操作系统文件锁未正确释放,因此锁会一直保留到超时。这将解释您对延迟锁定的观察,即使在断开其他客户端之后也是如此。您提到重新启动客户端计算机,但我怀疑重置主机文件服务器会立即释放锁定。

当然,在您的情况下,一个全新的基于服务器的解决方案将是最好的,可以生成一个中间解决方案以避免对 LabView 代码进行彻底检查。安装并设置 SQL Server,然后将 Access 数据库表更改为链接到 SQL 后端的表。每个 LabView 客户端都有自己的 Access DB 副本链接到同一服务器。这是一个快速而肮脏的描述,可能不是理想的,但它可以消除这个特殊问题。


推荐阅读