'Error in loading DLL' when building from source

[HughWarrington]

I'm using plugin version 4.0.34 in Access 365.

After exporting a database to source, I can't then rebuild from that source. The problem is related to a reference to the DAO library.

I've taken the original database, put a breakpoint in a dummy module, then added a watch on Application.VBE.ActiveVBProject.References. I've expanded the one causing problems later on import:

After doing a full export using the plugin, my vbe-references.json contains the following (other references removed for clarity):

{
  "Info": {
    "Class": "clsDbVbeReference",
    "Description": "VBE References"
  },
  "Items": {
    "DAO": {
      "GUID": "{00025E01-0000-0000-C000-000000000046}",
      "Version": "5.0"
    }
  }
}

So far so good. However when I do 'Build from source' having checked the Debug VBA Errors option, I get the following error:

Run-time error '48':
Error in loading DLL

This screenshot has the code, plus a bunch of watches on relevant things:

If I run 'Build from source' without checking the Debug VBA Errors option, I don't get any reported error in the log file at all, but the DAO reference is missing from the new .mdb file. Also, the end of the log file says this:

WARNING: The performance monitoring for operations still
had items in the call stack. This typically happens when
performance logging is started for an operation, but not
closed at the conclusion of the operation.
The call stack currently contains the following 2 items:
 - Add GUID References
 - Import TDF Data

I think there's three things that need to be looked at.

1. Is this the same issue as Object Library not registered #96? If yes, my error code was 48, not -2147319779, so the code needs to treat both error numbers as the same. If it's not the same issue -- then I'm stumped.
2. Also if it's the same issue as Object Library not registered #96, then I guess that list of magic numbers needs to be updated. Although it's disappeared from the latest code as far as I can see.
3. The error handling isn't right. It failed silently without a message in the log file about the failure to import a reference. It also gave that warning at the end which looks related.

Extra info. If I create a brand new database (running in Access 365 and choosing .mdb Access 2000 file format) the new database comes with a reference to DAO by default which looks like this:

I note that while the name is still 'DAO', everything else is different.

Seems weird to me that Access 365 has no problem loading my existing old .mdb with the old reference, but won't allow me to add that exact same reference to a new database.

[joyfullservice]

Thank you for your research and details that you have put into this issue! I will plan to take a closer look at this when I have a chance, perhaps later today or tomorrow.

[joyfullservice]

@HughWarrington - I have done some testing on my machine, and I have not been able to reproduce the issue. I am running Windows 11 and Office 2010 Pro (32-bit). If I change the default collation order for new databases to General - Legacy, I can save a database as Access 2000 format, which loads the DAO 3.6 library by default.

I have no issues doing a round-trip export and build from source on my system.

I can also create a new database in General collation (Office 2007 *.accdb format) and by default this will have the Office 14 DAO library.

If I remove the DAO reference, I can then add DAO 3.6 through this line of VBA code in the immediate window:

References.AddFromGuid "{00025E01-0000-0000-C000-000000000046}", 5, 0

I can also add this reference with the default version by specifying 0.0 as the version number, which is what your code was attempting to do. No errors or issue when I do this on my system.

References.AddFromGuid "{00025E01-0000-0000-C000-000000000046}", 0, 0

I can then go on to round-trip build from source with no issues.

Reviewing the specific error you are getting, (# 48), Microsoft has an article that lists a few potential causes... Maybe you have already seen this, but if not: https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/error-in-loading-dll-error-48

Just speculation here, but I am wondering if there is an issue with how the DAO 3.6 dll is registered on your system, or if this could possibly be a bitness issue... (You mentioned that you are running Office 365, but I am not sure if this would be the 32-bit or 64-bit version.)

One thing you might try from a troubleshooting angle is to use the above one-liner commands to attempt to add this reference to different versions of databases (i.e. Access 2000 mdb, a current *.accdb, etc...) and see if that might help pinpoint the incompatibility or confirm a DLL registry issue...

Hope that helps!

[bclothier]

Just as a FYI - DAO 3.6 is 32-bit only. If one were trying to use Access 64-bit, one would be better off with ACEDAO library which ships in both 64-bit/32-bit. Because ACEDAO is backward compatible, it's possible there may be weirdness if an Access file is built with DAO 3.6 but then loaded into Access 64-bit.

[HughWarrington]

Thank you both for the great ideas. I will do some more investigation when I get the chance and see what happens.

[hecon5]

oh, this brings back some memories when we switched from 32 bit to 64bit a while back.

We ran into similar issues like @bclothier mentioned. What we ended up having to do was to build the 32bit version, then manually switch the reference and export. This reset the reference and upon re-building from source the updated (ACEDAO) reference was correctly loaded. We did have issues when users tried to open the 32bit compiled version on 64bit office installations, which prompted some investigation way back when.

For Uncompiled (accda, accdb) files, we noticed that 99% of the time the reference was silently upgraded without issue. I actually notice that when I build this Addin because @joyfullservice has a different office version than I do (and therefore different references). Every once in a while it caused a hiccup, but we just rebuilt it and went on our merry ways.

Having users use the wrong compiled file was a fairly annoying PITHQ (Pain In The Hind Quarters), so we only provided a 32bit compiled version for a short while before all our users were upgraded to having 64bit office on their machines and once that happened, we removed the DAO3.6 reference and only use ACEDAO.

[HughWarrington]

Thanks both so much for your investigation @joyfullservice and advice.

A few more weird things, for the record:

• In the original database that I exported, the reference to DAO 3.6 is listed in the References dialog and works just fine, even though it's running in 64-bit Office 365.
• In the original database, in the References dialog, it says the path to the library is C:\Program Files\Common Files\Microsoft Shared\DAO\dao360.dll even though that file doesn't exist on my machine. The library is actually at C:\Program Files (x86)\Common Files\Microsoft Shared\DAO\dao360.dll.
• In the new database, References.AddFromGuid "{00025E01-0000-0000-C000-000000000046}", 0, 0 fails as described above. Going to the References dialog and adding the dll using the Browse... button does nothing at all: no error, no reference added. But running References.AddFromFile("C:\Program Files (x86)\Common Files\Microsoft Shared\DAO\dao360.dll") in the immediate window works! It adds the reference -- at the fake path C:\Program Files\Common Files\Microsoft Shared\DAO\dao360.dll.

Here are my conclusions:

• Access is doing some undocumented internal hackery to provide compatibility, which isn't very reliable.
• I can probably make a workaround if necessary using what I learned above.
• However, it's probably time to upgrade from DAO to ACEDAO anyway since it's supposed to be backward compatible according to @bclothier and others.

[bclothier]

Just to clarify this point:

Access is doing some undocumented internal hackery to provide compatibility, which isn't very reliable.

No it's not really. When code is compiled, it essentially caches the CLSIDs, IIDs and other COM internals. As mentioned, DAO and ACEDAO uses the same interfaces, so the code will continue to run since it'll find and use the interfaces from ACEDAO even though the references dialog says DAO 3.6. The difference is in the type library GUID which are different.

However, this is imperfect as you saw that sometime running with a cached definition against a different binary might result in a weird error. It's not "hackery" but simply the fact how COM works.

[HughWarrington]

@bclothier ok interesting, thanks for the details. You can certainly read 'undocumented internal hackery' as 'something @HughWarrington doesn't understand' ;) Having said that, I went to some lengths to read about this topic and didn't get very far -- and none of the good sources I've found were Microsoft.

Do you know why the References dialog points to a file that doesn't exist? Seems like something funny is going on concerning Program Files/Program Files (x86).

[bclothier]

One factor is that with Click-To-Run programs such as Office 365, they run in a sandbox that overlays the system folders. You can find some of the files by looking inside the folder vfs within the office folder in the program files. Those get virtualized to the path which is why you would see files listed in a dialog that you don't see in the file explorer.