We help IT Professionals succeed at work.

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

Bobby McKnight
on
2,386 Views
Last Modified: 2017-03-28
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.
Comment
Watch Question

CERTIFIED EXPERT
Distinguished Expert 2017

Commented:
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 McKnightSoftware Implementation Consultant for EcoSys

Author

Commented:
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.
CERTIFIED EXPERT
Distinguished Expert 2017

Commented:
Is the GUID different for each version?  Is that the correct GUID for Excel 2010?
President / Owner
CERTIFIED EXPERT
Fellow
Most Valuable Expert 2017
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION
Jim Dettman (EE MVE)President / Owner
CERTIFIED EXPERT
Fellow
Most Valuable Expert 2017
Commented:
This problem has been solved!
(Unlock this solution with a 7-day Free Trial)
UNLOCK SOLUTION
Jim Dettman (EE MVE)President / Owner
CERTIFIED EXPERT
Fellow
Most Valuable Expert 2017

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

Jim.
Bobby McKnightSoftware Implementation Consultant for EcoSys

Author

Commented:
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 McKnightSoftware Implementation Consultant for EcoSys

Author

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

Thanks a Bunch.