DAO360.dll in 2003 becomes what in 2010?

[jasmith4]

I have an Excel 2003 spreadsheet which communicates with an Access 2003 database, which works in WIndows XP / Office 2003, and I'm trying to get it to work in Windows 7 / Office 2010. This is out in production, so ideally I'd like to make no changes to either one of these files.

The problems is the spreadsheet's reference to Microsoft DAO 3.6, which in the XP/2003 world is in C:\Program Files\Common Files\MIcrosoft Shared\DAO. But the W7/2010 world is quite different, I guess -- DAO360.dll, DAO350.dll and DAO2535.dll don't exist any more, so where did all the stuff in the DAO library go?

I've tried adding to the spreadsheet a reference to the Microsoft Access 14.0 Object Library, but that doesn't help -- it won't compile, because it still doesn't know what a Database object is!

Cross-posted here: http://www.mrexcel.com/forum/showthread.php?t=638448

 

[delaneyjm]

Microsoft does not support DAO any longer under Windows 7. You will need to update all VBA code to use ADO

 

[xenou]

^^ Rumors of DAO's demise are much exaggerated. It works just fine and is still an excellent choice for working with an Access database (DAO is more like a "native language" for Access then ADO).

 

[jasmith4]

The problem is that the default location of DAO360.dll has changed, from C:\Program Files\Common Files\Microsoft Shared\DAO to C:\Program Files (x86)\Common Files\Microsoft Shared\DAO. So when I bring over my spreadsheet that works fine in XP/2003, its reference to DAO360.dll in the former location is invalid in W7/2010. That means, just because of that reference, I have to maintain two versions of the spreadsheet.

I've implemented in InstallShield a rather clumsy solution which would make Microsoft techies cringe, namely finding the existing and registered DAO360.dll on the target system and copying it to C:\Program Files\Common Files\Microsoft Shared\DAO, creating that folder if it doesn't exist. It doesn't re-register the DLL there, but it's there so that my spreadsheet, installed via the InstallShield package, can find it and thus run. Is there really no better way?

 

[lnell003]

I can confirm that just copying the library to the other location solves the problem. I did not use any install shield whatsoever. All good thanks.