[RESOLVED] 32/64 problem with ADO

[couttsj]

Ran into an interesting problem using ADO. When I was developing on a 32 bit OS, there was never a problem, but now that I am developing on a 64 bit OS, programs compiled on the 64 bit OS don't run on the 32 bit system. Library files referenced in Windows\Syswow64 are not a problem, as the OS is smart enough to recognize that System32 on a 32 bit system is the same as Syswow64 on a 64 bit system.

The same does not appear to be true for ADO library files. On a 32 bit system, they are located in "\Program Files\Common Files\System\ado", but on a 64 bit system they are located in "\Program Files (x86)\Common Files\System\ado". A program using ADO compiled on a 32 bit system runs on a 64 bit system, but the same program compiled on a 64 bit system does not run on the 32 bit system.

Do I do all the compiling on the 32 bit system, or is there another way around this problem besides separate installation packages?

J.A. Coutts

[Elroy]

WOW, I'm quite interested in this one.

I primarily use the DAO, which doesn't seem to have this problem at all. However, in the near future, there will be some Oracle SQL Server uploading, and that requires the ADO. That Oracle piece isn't "live" yet, but I'd sure like to know about any problems I'm going to have.

All of my development has been on a 64-bit computer and 64-bit OS for quite some time. And my users use a hodge-podge of hardware and OSs. Although I do know that it's all Intel (actually Dell boxes) and Windows.

Good Luck Getting It Sorted,
Elroy

EDIT1: Actually, there are a couple of installations about which I'm not sure (hardware). However, I would have heard if they were having any problems like this.

[dilettante]

The File System Redirector takes care of these special folders... unless you have done something to interfere with it.

As far as I can tell there has never been an issue aside from the dying Windows 7 SP1 that has lots of development landmines in it.

[couttsj]

The error I encountered when trying to run the 64 bit executable on the 32 bit OS was "Problem Loading Program. Type mismatch!". What clued me into the source of the problem was the fact that after I moved the code from the 64 bit system to the 32 bit system and tried to run it in the IDE, I got the message "Compile error: User-defined type not defined" on the line "Public adoConn1 As ADODB.Connection". When I examined the References, it showed "(MISSING) Microsoft ActiveX Data Objects 6.1 Library". I had to remove the one in the "Program Files (x86)" directory and add the one in the "Program Files" directory (same library name "msado15.dll"). Once compiled on the 32 bit system, the executable ran just fine.

Dilettante may have hit on something though. This 32 bit OS is Windows Vista SP2, and it may not be able to handle the redirect. Unfortunately it is the only 32 bit system I have access to.

J.A. Coutts

[dilettante]

The redirect only occurs in a 64-bit version of Windows.

It sounds more likely you are developing on Windows 7 SP1 with the "ADO broken compatibility" bug.

There are hacks and workarounds, but your best bet is to move to Windows 10. The bug was never properly fixed until Windows 8, and never will be.

[couttsj]

The redirect only occurs in a 64-bit version of Windows.

It sounds more likely you are developing on Windows 7 SP1 with the "ADO broken compatibility" bug.

Sorry, no Win 7 here. Executable was compiled on Win 8.1(64 bit) and attempted to run on Win Vista(32 bit). It is possible that Windows (64 bit) treats this like an unregistered .DLL file, which searches the Windows directory, then the Windows System directory, and finally the installed path. When is can't find "msado15.dll" in the "Program Files" path, then maybe it searches the "Program Files (x86)" path. Either that or it recognizes the executable as a 32 bit program and goes directly to the "Program Files (x86)" path.

The 32 bit system only has one path, and it would be nice to know if later 32 bit systems have this same issue.

J.A. Coutts

[dilettante]

A 32-bit process always get filesystem redirection unless it has specifically made a call to temporarily suspend it.

Here is your problem:

(MISSING) Microsoft ActiveX Data Objects 6.1 Library

There is no support for the ADO 6.1 interfaces before Windows 7.

Save yourself some grief, use the "universal interfaces" ADO 2.5 typelib unless your programs are using some of the newer features in 2.6, 2.7, or 2.8 to work. Most of these were for later versions of SQL Server and Oracle though Named Parameters introduced in 2.6 are still useful with a Jet 4.0 or ACE database.

These are all just type libraries which point to implementations within msado15.dll itself.

This was covered in an old (2001?) MS KB article on ADO portability, but it doesn't seem to be online anymore.

[couttsj]

Well dilettante, you hit the nail on the head. That was indeed the problem. When I look back at the original implementations (2012), I did indeed use the ADO 2.5 tlb. Somewhere along the line it got changed. When I use that reference, the executable works just fine in both systems.

Is there any kind of summary available for what these various references do? There are 7 of them listed on my system.

Thank you.

J.A. Coutts

Edit: Wikipedia offers not a bad summary
https://en.wikipedia.org/wiki/Micros...ess_Components

[dilettante]

ADO 6.1 was a sort of band-aid on issues I haven't seen documented anywhere. From remarks by Microsoft folks it seems to mostly differ from ADO 6.0 in disabling RDS server support (which was finally ripped out of the DLL itself in Windows 8?).

ADO 6.0 interfaces are nearly identical in function to those of ADO 2.8 aside from changes to support ADO hosted in IE 7 and later on Vista and later when "Protected Mode" is active.

Aside from that see: ADO Features for each Release.

[Krool]

The redirect only occurs in a 64-bit version of Windows.

It sounds more likely you are developing on Windows 7 SP1 with the "ADO broken compatibility" bug.

There are hacks and workarounds, but your best bet is to move to Windows 10. The bug was never properly fixed until Windows 8, and never will be.

There is an official KB hotfix for Win 7. So don't say hacks and workarounds, maybe prior to that hotfix but not for now...

[dilettante]

See KB2698365 Breaks Legacy ADO. The hacking goes on and on and on.

Windows 7 is unsafe for any usage, and unfit as a development platform. Period.

[Krool]

See KB2698365 Breaks Legacy ADO. The hacking goes on and on and on.

Windows 7 is unsafe for any usage, and unfit as a development platform. Period.

That's old and solved as of today.
Nevermind we should avoid running in circles about this.