Avatar of Bobby McKnight
Bobby McKnight
Flag for United States of America asked on

MS Access, Run-time error 48 Error Loading dll after upgrading from 2013 64-bit to 2016

I've developed a small Access database to generate reports in Excel for myself and co-worker.  I have code in an auto execute macro that is supposed to find any broken references, remove them, then add the Excel reference based on GUID.  I've been doing it this way because my co-worker still has Excel 2010 on his pc and we can't upgrade b/c he works for another contractor.  This worked fine until I upgraded to Office 2016.  Now I get a Run-time error 48: Error Loading DLL on line 3 every time I open the database.

Dim strGUID As String
strGUID = "{00020813-0000-0000-C000-000000000046}"
Access.References.AddFromGuid strGUID, 1, 0

Open in new window

The code above still works on the other pc.  I've done a little research and most things point to missing registry keys for  ACEDAO.DLL and dao360.dll but I've checked the registry and both those keys are present.  Has anyone ran into this issue before and is there a way of solving it without having to completely reinstall Office.
* dllMicrosoft Access

Avatar of undefined
Last Comment
Bobby McKnight

8/22/2022 - Mon

The bit-version of Office is what is important.  A single database will not work for both the 32-bit version of Office and the 64-bit version without using conditional compilation.  Computers have been 64-bit for many years and so OS's have been also.  A 64-bit version of Office has been available also for many years but due to compatibility issues, MS still recommends that you NOT use the 64-bit version of office unless you have some particular need to support humongous worksheets.  Once you determine that you need 64-bit Excel, all of Office must be 64-bit.  You can't mix and match.

To solve your problem, you might be able to use conditional compilation to switch between 34-bit API calls and 64-bit API calls.  But, if you distribute as an .accde, you must compile each using the appropriate version of Office.  I don't think the  compiler directive solves the problem since the code has to be compiled and that requires knowledge of the bit-version ahead of time.
Bobby McKnight

We are both using 64-bit versions of Office.  I updated from Office 2013 32-bit to 64-bit in order match my co-worker's 64-bit version and increase Excel performance back in January.  I converted the few pieces of code that conflicted between the bit versions at that time or the ones that I found that didn't work at least.  I didn't put in the code for adding the Excel reference until after the upgrade from Office '13 32-bit to 64-bit.  Then our whole company was moved to Office 2016 64-bit a few weeks ago.   The code in question still worked in Office 2013 64-bit.  So far it's only been isolated to may machine.

Is the GUID different for each version?  Is that the correct GUID for Excel 2010?
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
Jim Dettman (EE MVE)

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
Log in to continue reading
Log In
Sign up - Free for 7 days
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
Jim Dettman (EE MVE)

Oh and you might want to try just first opening Excel and letting it "repair".   If that doesn't work, then re-install.

Bobby McKnight

As far as I know, they are the same.  I have a separate function that will print the Reference Properties for all assigned references  in the Immediate window.  The GUID came up the same on both machines.  The version # is different but the GUID is the same.  I included the Reference properties below.

Name:         VBA
FullPath:     C:\Program Files\Common Files\Microsoft Shared\VBA\VBA7.1\VBE7.DLL
Version:      4.2
GUID:         {000204EF-0000-0000-C000-000000000046}
Name:         Access
FullPath:     C:\Program Files\Microsoft Office\Root\Office16\MSACC.OLB
Version:      9.0
GUID:         {4AFFC9A0-5F99-101B-AF4E-00AA003F0F07}
Name:         stdole
FullPath:     C:\Windows\system32\stdole2.tlb
Version:      2.0
GUID:         {00020430-0000-0000-C000-000000000046}
Name:         DAO
FullPath:     C:\Program Files\Common Files\Microsoft Shared\OFFICE16\ACEDAO.DLL
Version:      12.0
GUID:         {4AC9E1DA-5BAD-4AC7-86E3-24F4CDCECA28}
Name:         Office
FullPath:     C:\Program Files\Common Files\Microsoft Shared\OFFICE16\MSO.DLL
Version:      2.8
GUID:         {2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}
Name:         Excel
FullPath:     C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE
Version:      1.9
GUID:         {00020813-0000-0000-C000-000000000046}
Bobby McKnight

There were left over keys for 1.8 and 2.5.  The code worked perfectly after deleting those old registry entries.

Thanks a Bunch.
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.