从文档中，我希望adModeShareDenyWrite是这种方式，但是它不能正常工作。

我正在通过ADO使用Access数据库。我的连接字符串显示为Mode = 8，即adModeShareDenyWrite。但是，当我尝试从表中删除一行时，我得到：

未指定的错误，描述：无法从指定的表中删除。，源：Microsoft JET数据库引擎

换句话说，该设置阻止ME使用我的OWN连接来更新数据库。

我在网上发现了其他几篇报道相同内容的文章，与Access一起使用的adModeShareDenyWrite设置未按文档所述工作。

我正在寻找不涉及管理员更改权限的解决方案。它必须是我的程序可以控制的东西。

我的动机是最大程度地减少数据库损坏的机会。 Microsoft记录的mdb文件损坏的原因之一是两个写入同一数据库的应用程序。因此，我想确保只有一个应用程序可以与数据库建立写连接。其他人可以阅读，但尝试书写时会失败。首先建立联系的人将获胜。

解决方案

一种解决方案是授予他们访问数据库副本的权限。他们可以更改他们想要的任何内容，但不会超出我们将其复制到主数据库的范围。

我想我们在这里可以从客户端界面访问MDB文件，无论它是什么，其他人也可以同时连接到同一文件。当在连接模式下使用adModeShareDenyWrite时，这意味着我们仍然可以与其他人共享数据(在MDB文件中的表或者记录上没有任何类型的锁)，但是无法修改(这就是为什么会收到错误消息的原因) )。

一种解决方案是使用以下方法管理连接参数：

(where you have a user object with a '.role' property, or anything equivalent ...)
if activeUser.role = "admin" then
    m_connectionMode = adModeWrite
else
    m_connectionMode = adModeShareDenyWrite
endif

然后，我们可以使用参数m_connectionMode打开ADO连接。管理员将有权插入/更新/删除，而其他用户则只能查看数据。这意味着我们在程序中的某个位置，或者理想情况下在表格中，有一些数据表明谁在应用程序中。

编辑：以下与科里的多重注释：

我们将无法直接做自己想做的事情。我的建议：当应用访问数据库时，它将检查.mdb文件夹中的特殊文件(无论文件是什么)。

如果该文件存在，则该应用程序将打开"只读"连接。

如果该文件不存在，则应用程序将创建文件(例如，我们可以使用" transferDatabase"创建一个文件)并打开一个读写连接。退出应用程序后，销毁文件。

科里·特拉格(Corey Trager)写道：

I am looking for a solution that
  doesn't involve an administrator
  changing permissions. It needs to be
  something that my program can control.

好吧，如果问题是由于NTFS权限对用户而言是只读的，则我们无法做任何事情来使MDB可写。我们没有指定在服务器上还是在本地硬盘上存储MDB的位置，但是无论哪种情况，要使用户对MDB拥有WRITE权限，必须将NTFS权限设置为允许它(对于共享在服务器上，必须同时在SHARE和基础文件上都允许)。如果它是本地文件，最好的解决方案是确保将文件存储在用户级登录具有完全WRITE权限的位置。这将在用户个人资料中的任何地方，几乎没有其他地方。

就是说，我并不是真的在暗示这是我们问题的根源(我真的不能说一种或者另一种方式)，只是指出如果是原因，那么我们就不能做任何该死的事情。以编程方式解决该问题。

科里·特拉格写道：

My motivation here is to minimize the
  chances of database corruption. One of
  the causes of mdb file corruption
  documented by Microsoft is two apps
  writing to the same db. So, I want to
  make sure that only one app can have a
  write connection to the db. Others can
  read, but should fail when they try to
  write. Whoever makes a connection
  first wins.

你为什么担心呢？默认情况下，Jet是多用户数据库引擎。如果其他人正在更新表，则涉及的数据页将被锁定为只读(处于写入开始之前的状态)。

没有现实的理由担心仅仅多用户交互会导致腐败。 Jet数据库损坏通常是由于连接断开或者写入过程中连接中断而导致的(例如，强迫退出应用程序的用户响应速度不够理想)。

我认为我们对腐败的担心放错了地方。

另一方面，我们仍然应该可以使用排他锁打开，但我不确定为什么它不起作用。我们是否考虑过使用DAO而不是ADO处理Jet数据？鉴于它是本机数据接口(而不是通用接口层)，因此应该更简单。

如果我们有多个用户通过网络连接到Access数据库，则可能需要考虑升级到SqlServer而不是使用Access。