用于列出当前数据库用户的 OpenSchema 错误 3251

Error 3251 on OpenSchema to list current DB users

我有两个同一个 BE 的数据库,一个是旧的,它的替代品是由一个较新的项目制成的。表和它们的结构相同,只是数据不同。

我正在 FE 上创建一些可用的自动维护选项,以便其他没有任何 ACCESS 知识的人可以执行任务,例如从主 DB 中获取特定记录并将其转移到 Archive-dedicated 记录。为此,我需要检查除了进行维护的一个用户之外是否还有其他人连接到数据库。如果是,直接中止,如果不是,继续(至少现在,我以后会改进的)。

我正在尝试通过使用此 OpenSchema 查询列出所有活动的数据库用户来进行此验证:

cn.OpenSchema(adSchemaProviderSpecific, , "{947bb102-5d43-11d1-bdbf-00c04fb92675}")

(cn 是一个 ADODB.Connection 对象)

但我不明白为什么,它 returns 在较新的数据库上出现错误 3251 "Object or provider is not capable of performing requested operation",而它的旧版本却运行良好(具有相同的 ConnectionString)。我可以手动复制工作数据库中的表,但我预计与从 ACCDB 中干净地提取 BE 相比,它会造成隐藏的麻烦,甚至没有提到任何可能的人为错误。

我试图比较这两个数据库并发现任何可以解释行为的差异(逐一检查数据库和项目属性,自动和手动连接,有和没有表、模块、密码等...) ,但我 运行 没主意了。

任何人都知道或提示可能导致此问题的原因吗?如果需要,我可以提供两个数据库的剥离版本(无论是否包含任何内容都给出相同的结果)。

当然,如果您有另一种解决方案来检查用户是否是唯一使用数据库的用户并且完全绕过 OpenSchema 方法,我洗耳恭听。

2018 年 3 月 10 日更新

这是用于验证的函数。

Public Function checkMultipleUsers()

    Dim cn As New ADODB.Connection
    Dim rs As New ADODB.Recordset
    Dim nbUsers As Integer

    cn.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;" & _
                          "User ID=Admin;" & _
                          "Data Source=\SERVERPATH\Project_BE.accdb;" & _
                          "Mode=Share Deny None;" & _
                          "Extended Properties="""";" & _
                          "Locale Identifier=1036;" & _
                          "Jet OLEDB:System database=C:\Users\MyUser\AppData\Roaming\Microsoft\Access\System.mdw;" & _
                          "Jet OLEDB:Registry Path=Software\Microsoft\Office.0\Access\Access Connectivity Engine;" & _
                          "Jet OLEDB:Database Password=""PASSWORD"";" & _
                          "Jet OLEDB:Engine Type=6;" & _
                          "Jet OLEDB:Database Locking Mode=0;" & _
                          "Jet OLEDB:Global Partial Bulk Ops=2;" & _
                          "Jet OLEDB:Global Bulk Transactions=1;" & _
                          "Jet OLEDB:New Database Password="""";" & _
                          "Jet OLEDB:Create System Database=False;" & _
                          "Jet OLEDB:Encrypt Database=False;" & _
                          "Jet OLEDB:Don't Copy Locale on Compact=False;" & _
                          "Jet OLEDB:Compact Without Replica Repair=False;" & _
                          "Jet OLEDB:SFP=False;" & _
                          "Jet OLEDB:Support Complex Data=True;" & _
                          "Jet OLEDB:Bypass UserInfo Validation=False;" & _
                          "Jet OLEDB:Limited DB Caching=False;" & _
                          "Jet OLEDB:Bypass ChoiceField Validation=False"
    cn.Open

    nbUsers = 0

    ' The user roster is exposed as a provider-specific schema rowset
    ' in the Jet 4.0 OLE DB provider.  You have to use a GUID to
    ' reference the schema, as provider-specific schemas are not
    ' listed in ADO's type library for schema rowsets

    Set rs = cn.OpenSchema(adSchemaProviderSpecific, _
    , "{947bb102-5d43-11d1-bdbf-00c04fb92675}")

    While Not rs.EOF
        If rs.Fields(2) = True Then
            nbUsers = nbUsers + 1
        End If
        rs.MoveNext
    Wend

    If nbUsers = 1 Then
        checkMultipleUsers = False
    ElseIf nbUsers > 1 Then
        checkMultipleUsers = True
    Else
        MsgBox ("ACCESS can't determine the number of users. Operation aborted.")
        checkMultipleUsers = 0
    End If

    rs.Close
    cn.Close

    Set cn = Nothing
    Set rs = Nothing

End Function

我主要从 CurrentProject.ConnectionString 的查询中获得了 ConnectionString 参数,但将它们减少到下面的参数也不起作用,所以我不认为它们会成为问题。

cn.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;" & _
                      "Data Source=\SERVER\Project_BE.accdb;" & _
                      "Jet OLEDB:System database=C:\Users\MyUser\AppData\Roaming\Microsoft\Access\System.mdw;" & _
                      "Jet OLEDB:Registry Path=Software\Microsoft\Office.0\Access\Access Connectivity Engine;" & _
                      "Jet OLEDB:Database Password=""PASSWORD"";"
cn.Open

好吧,碰巧数据库很可能已损坏,并且可能搞砸了 RAM 中的某些内容以供 Access 使用,因为我尝试创建一个全新的数据库并将有问题的数据库的每个元素复制到更新的数据库中遇到了这个错误,几天后,它当时没有用。

我没有想到的是,我们从来没有在工作时关闭我们的计算机,以便 IT 人员可以在晚上进行维护,因此 RAM 永远不会从一天到另一天完全刷新。

这周尝试了完全相同的方法,效果非常好。我想 IT 需要重新启动所有 PC,否则自从我上次尝试后我们就出现了电力故障。

是的。感谢 Access 在过去的几周里无所事事地令人头疼,并感谢我没有考虑进行适当的重启以重新开始(几年前实际上得到了类似的东西,proc 只会拒绝启动它所在的文件或它的调用方式,两天后重新启动计算机,它就像一个魅力一样工作)。