joyfullservice / msaccess-vcs-addin

Synchronize your Access Forms, Macros, Modules, Queries, Reports, and more with a version control system.
Other
204 stars 40 forks source link

'Error in loading DLL' when building from source #534

Open HughWarrington opened 1 day ago

HughWarrington commented 1 day ago

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:

image

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:

image

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 #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 #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:

image

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 commented 1 day ago

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 commented 6 hours ago

@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.

image

image

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.

image

image

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 commented 5 hours ago

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.