OpenSchema出现错误3251,以列出当前的数据库用户

时间:2018-10-02 16:29:49

标签: ms-access-2013

我有两个具有相同BE的DB,一个是旧的,而它的替换来自一个新项目。表及其结构相同,只是数据不同。

我正在FE上创建一些可用的自动维护选项,以便其他不具有ACCESS知识的人可以执行任务,例如从主DB移出特定记录,然后移向一个Archived专用的记录。为此,我需要检查是否只有一个用户在进行维护,而没有其他人与数据库连接。如果是,则中止;否则,请继续(至少就目前而言,我将在稍后进行改进)。

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

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

(cn是ADODB.Connection对象)

但是我不知道为什么,它在较新的DB上返回错误3251“对象或提供者无法执行请求的操作”,而其旧的self就像一个超级按钮(使用相同的ConnectionString)。我可以手动将表复制到工作数据库中,但是与从ACCDB干净地提取BE相比,我希望它会引起隐藏的麻烦,甚至不提任何可能的人为错误。

我试图比较两个数据库,并找出可以解释该行为的任何差异(一个接一个地检查数据库和项目属性,自动和手动连接,有无表,模块,密码等),但是我的想法不多了。

任何人对导致此问题的原因有任何想法或提示?如果需要,我可以提供两个DB的精简版本(其中包含任何内容或给出的结果都不相同)。

当然,如果您有另一种解决方案来检查用户是否是唯一使用数据库的用户,并且完全绕过OpenSchema方法,那么我就不知所措了。

更新03-10-2018

这是用于进行验证的功能。

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\15.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\15.0\Access\Access Connectivity Engine;" & _
                      "Jet OLEDB:Database Password=""PASSWORD"";"
cn.Open

1 个答案:

答案 0 :(得分:0)

好吧,碰巧数据库很可能已损坏,并且可能在RAM中弄乱了一些东西供Access使用,因为我尝试创建一个全新的数据库并将遇到问题的每个元素复制到较新的数据库中。错误和几天后,当时它不起作用。

我没想到的是,我们从不关闭计算机,以便IT部门可以在晚上进行维护,因此RAM从一天到一天都不会被完全清空。

本周尝试过完全相同的事情,它的工作原理就像是一种魅力。我想IT部门需要重启所有PC,否则自上次尝试以来我们就出现了电力故障。

是的。感谢Access在过去的数周中让您头痛不已,而且感谢我没有考虑进行适当的重新启动以重新启动(实际上几年前就已经有了类似的东西,proc只会拒绝启动文件所在的目录或的方式,两天后重新启动了计算机,它就像一个咒语。)