-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'Error in loading DLL' when building from source #534
Comments
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. |
@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 I have no issues doing a round-trip export and build from source on my system. I can also create a new database in If I remove the DAO reference, I can then add DAO 3.6 through this line of VBA code in the immediate window:
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.
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! |
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. |
Thank you both for the great ideas. I will do some more investigation when I get the chance and see what happens. |
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 ( 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. |
Thanks both so much for your investigation @joyfullservice and advice. A few more weird things, for the record:
Here are my conclusions:
|
Just to clarify this point:
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. |
@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 |
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 |
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):So far so good. However when I do 'Build from source' having checked the Debug VBA Errors option, I get the following error:
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:
I think there's three things that need to be looked at.
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.
The text was updated successfully, but these errors were encountered: