open accdr file protected with database password

Access has it's power of security , no problem , but my question is :

this way , you give us ,doesn't reduce the power of this security of the MS Access for cracking , does it ?

I'm not sure I understand your question, but I don't see this technique as weakening or bypassing the security of the database password -- you do have to supply the password to open the database.  It just bypasses what in my view is a weakness of the runtime structure, that it requires you to specify a database when opening access, but there is no way to specify the database password on the command line, the way there is for user-level (workgroup) security.

Understand, I don't speak for Microsoft in this matter.  I just tried to find a solution to a practical problem.

Hi dear

thanks alot

Access has it's power of security , no problem , but my question is :

this way , you give us ,doesn't reduce the power of this security of the MS Access for cracking , does it ?

regard

Hi dear

Thanks alot , it's great

1- why do you use of  Dumy database , what's it's work ?

2- Is there any relation between Dumy database and  the password?

3-Is ther anyway to lose the password like anybody copy the database when it is running and take the database without password or for example , can anybody ( or cracker ) takes the password from Dummy databse or etc ?

regard

1 - The dummy database allows us to open Access in runtime mode (that is, with the /runtime switch) without yest specifying the password (since we can't provide it on the command line).  You can't open Access in runtime mode without specifying a database to be opened; Access won't allow it.  So we create a dummy database to pass on the command line, with no database password.  Then, once that database is open, we get a reference to that instance of Access and use automation to close the dummy database and open the protected database, specifying the password.

2 - There is no relationship between the Dummy database and the password.  It's an empty database.  If it doesn't already exist from a previous run of the procedure, the procedure creates it.

3 - The password can't be stolen from the dummy database, because that database has no password.  If someone has a copy of the protected database, I  don't know how hard it is to crack the password, but I do know that it's a lot harder than it was in earlier versions of Access.  I doubt that copying the database while it's running would make it easier to recover the password, but I don't know the technical details of how this security is implemented, so I can't say for sure.  On the other hand, it seems reasonable that some sort of process observer could capture the password from memory at the moment the database is opened and the password is supplied.

I'd be inclined to say that, anyone who has a copy of the protected database could, with sufficient effort, crack the password.  It's just a question of how much time and effort is required.  The security provided by the database password is not intended to protect national secrets or million-dollar assets.

Hi dear

Thanks alot , that's great

1- why do you use of  Dumy database , what's it's work ?

2- Is there any relation between Dumy database and  the password?

3-Is ther anyway to lose the password like anybody copy the database when it is running and take the database without password or for example , can anybody ( or cracker ) takes the password from Dummy databse or etc ?

regard

The code below, though clumsy, works for me with a full installation of Access.  I don't know if it works with only the Access runtime installed; I suspect it may not, but please test it if you can.

'------ start of code ------

Sub StartPasswordedDatabaseRuntime( _

        strPathToDatabase As String, _

        Optional strPassword As String, _

        Optional strPathToRuntime As String, _

        Optional blnQuit As Boolean)

    ' Start a runtime database that has a database password.

    Dim appRT As Access.Application

    Dim strPathToDummy As String

    Dim blnStillOpen As Boolean

    Const Q As String = """"

    If Len(strPassword) = 0 Then

        strPassword = InputBox("Please enter password:")

    End If

    If Len(strPathToRuntime) = 0 Then

        strPathToRuntime = SysCmd(acSysCmdAccessDir) & "msaccess.exe"

    End If

    strPathToDummy = CurrentProject.path & "\Dummy.accdb"

    If Len(Dir(strPathToDummy)) = 0 Then

        Application.DBEngine.CreateDatabase strPathToDummy, dbLangGeneral, dbVersion120

    End If

    Shell _

        Q & strPathToRuntime & Q & " " & Q & strPathToDummy & Q & " /runtime", _

        vbNormalFocus

    Set appRT = GetObject(strPathToDummy)

    With appRT

        .CloseCurrentDatabase

        .OpenCurrentDatabase strPathToDatabase, , strPassword

    End With

    On Error Resume Next

    blnStillOpen = True

    Do While blnStillOpen

        DoEvents

        Err.Clear

        If appRT Is Nothing Then

            blnStillOpen = False

        ElseIf Len(appRT.CurrentProject.path) = 0 Then

            blnStillOpen = False

        End If

        If Err.Number <> 0 Then

            blnStillOpen = False

        End If

    Loop

    If blnQuit Then

        Application.Quit   ' if we're done here.

    End If

End Sub

'------ end of code ------

Please note that the database where this code runs remains open, with the procedure code looping, while the runtime database is open.  I've tried various methods to release that database to user control and exit, but so far without success.