【问题标题】:Access 2013 DB changes mysteriously to read onlyAccess 2013 DB 神秘更改为只读
【发布时间】:2018-10-14 22:47:38
【问题描述】:

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

你有什么想法吗?

提前致谢!

【问题讨论】:

  • 是实际文件被更改为只读,还是只是在 Access 中以只读模式打开?
  • 好点,当我打开数据库时,文件顶部有一个信息图标,上面写着“只读数据库已以只读方式打开。您只能更改链接表中的数据. 要进行设计更改,请保存数据库的副本”。
  • 在可以“随机打开数据库”的 10 个用户之间,这是否还包括从 Access 中打开数据库(而不仅仅是通过 LabView 代码)?测试工程师是否可以打开数据库来更改数据库架构?从技术上讲,这可以在不打开 Access 的情况下完成,也可以使用数据定义库对象和方法。
  • 您是否检查了包含文件夹的用户权限?他们不仅需要文件的读/写权限,还需要文件所在的文件夹。 LabView 代码运行的安全上下文是什么?它是否可以改变,即使对于单个测试工程师,可能在具有不同操作系统或网络安全配置的不同计算机上运行它?这方面有什么变化吗?
  • 顺便说一句,你应该知道如何让它再次读/写并且对那个细节不感兴趣,但你仍然应该准确地分享你为解决这种情况所做的事情,即使你不知道为什么它正在发生。一个可行的解决方案可以潜在地指出原因,或者至少可以限制可能的原因。

标签: ms-access ms-access-2013 labview


【解决方案1】:

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

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

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

【讨论】:

  • 在“链接 Access 数据库”解决方法中,如果两个客户端尝试对数据库进行冲突更改会发生什么?
  • 我想这取决于“冲突”的含义。我不确定通过 Access 的 SQL Server 是否支持记录级别锁定(您必须对此进行研究),但 SQL Server 肯定有自己的机制来避免冲突或损坏。但是,如果这是您关心的问题,那么现在如何处理呢?即使 Access 也不会阻止一个客户端更改记录,然后让另一个客户端在所有情况下更改相同的记录。仅当当前记录正在被编辑和锁定时,它才会阻止此类更改,但是通过 LabView 客户端的自动更新是否冲突?在研究中一切顺利。
猜你喜欢
  • 2013-11-23
  • 2014-02-05
  • 1970-01-01
  • 2014-06-15
  • 1970-01-01
  • 1970-01-01
  • 2011-12-15
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多