Access: DAO reference guid changed, resulting in an .mde not starting up in Access 14 (2010) on Win7

2 Feb 2011: I started this thread under the impression that my M$ technet thread about it was dead. But there is a new post about the subject, please have a look at it: http://social.technet.microsoft.com/Forums/en-US/officeitpro/thread/56e098b9-210b-4afe-8531-c526fb3e44641. Not a solution, but a confirmation that the combination of 7, 14 and mde is crucial.

--Original Post:

Since we still have clients using Office 9 (2000), we deploy our frontend in an .mde file format (database format of Access 2000) for all Access versions 9 to 14 (2010) rather than "compiling" an .mde for older and an .accde for newer Access versions. Due to their economic situation, we often find a mixture of all Office and Windows versions on our clients' workstations in one company, so the least possibility is our answer. This was no problem with an .mde until Office 14 in combination with Windows 7. I analyzed everything enough to be sure now that there is a reproducible issue with an .mde starting up in Access 14 in combination with Windows 7 -- Access 14 on XP will work.

We have some references in our VBA project, among them Word and DAO. The Word ref. works on every Access version 9 to 14 without a problem, it will automatically find the appropriate version since the guid is the same from Office 9 to 14. Between Office 12 (2007) and 14 (2010) M$ changed not only the dll file name for DAO but, what's crucial in my understanding, the reference GUID. Have Access detect the new DAO version will fail under Access 14 under Windows 7, but only with an .mde, an .mdb, an .accdb and an .accde will start up without a problem, and an .mde will start up in Access 14 under XP, as men开发者_JAVA百科tioned. So this is a combination of the changed GUID and a system right to ... do what? Find a file, scan the registry for the information necessary here?

I assume there will not be a one or two step "trick" for this, but I would be grateful for hints what to check in Windows 7, or even, how to change our VBA code to get rid of this problem. Regarding the last option: We have many, many explicit Dim ... As DAO.... throughout our code.

---

As code won't format properly in the comments windows I have to use an answer. Please run the following code and report back the results.

Sub ViewMoreReferenceDetails()

Dim refIDE As Object

    For Each refIDE In Access.Application.VBE.ActiveVBProject.References
        If refIDE.IsBroken = True Then
            Debug.Print "Broken, GUID - " & refIDE.Guid
        Else
            Debug.Print refIDE.Description & " - " & refIDE.Name & " - " & _
                refIDE.Major & "." & refIDE.Minor & vbCrLf & _
                "       Location - " & refIDE.FullPath
        End If
    Next refIDE

End Sub

---

I'm surprised a Word reference to a specific version will fix itself. I always use late binding with anything other than the default 3 Access references, Access, VBA and DAO.

DAO can be a problem in certain situations, and one of those is if you've got multiple versions of Access installed on the machine where you compile the MDE or in the production environment. An incomplete re-registration of Access can cause it to be broken, even though it's registered as the main version of Access. A complete run of the installation (or a repair of the Office install) should fix that.

For other considerations, see Michael Kaplan's article on the subject of references. It touches on DAO registration issues, and specifically mentions the case where DAO is broken, but IsBroken returns False nonetheless. What he says there may give you some ideas on some approaches for the problem.

But in my experience, the error you're getting is a sign of a corrupted Access installation.