Link to home
Start Free TrialLog in
Avatar of Bobby McKnight
Bobby McKnightFlag 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.
Avatar of PatHartman
PatHartman
Flag of United States of America image

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.
Avatar of Bobby McKnight

ASKER

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?
ASKER CERTIFIED SOLUTION
Avatar of Jim Dettman (EE MVE)
Jim Dettman (EE MVE)
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Oh and you might want to try just first opening Excel and letting it "repair".   If that doesn't work, then re-install.

Jim.
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}
There were left over keys for 1.8 and 2.5.  The code worked perfectly after deleting those old registry entries.

Thanks a Bunch.