64-bit ODBC drivers for Access (Office 2016)

> I needed the 64-bit odbc drivers for Access databases

Why?

The best practice is to use the 32-bit MSI installation of Office, especially if you want to use other drivers or Automation.

Some of us initially thought that CTR was just a more convenient way of buying Office and getting it on your machine. If MSFT had left it at that, great, but no, they had to drag in some virtual machine that Office now runs in which has the nasty side effect of no Automation with the rest of the world, and we now have these conflicts between MSI and CTR installations. From where I sit, it's not a pretty sight, but there you have it.

Thanks for the quick reply, Tom.

Because - we have our own data-processing engine in 32 and 64 bit form and I need to check out the 64-bit version fully.

In the end, even though I'd read somewhere that they were buggy, I thought I'd try the 2010 drivers by downloading 64-bit Access 2010 run-time. It installed without a problem and the driver works like a dream with our software. Hopefully I won't encounter any bugs that aren't covered by updates.

But it's seriously weird that the Office 2016 installation doesn't install the drivers.

I am running with Windows 10 - 64 bit processor.

I am trying to steup "accessruntime_4288-1001_x64_en-us.exe", get setup error, cant install due to finding 32 bit programs. how do I do it?

Can't find how to fix clash of programs 64 vs 32 or 16.

The simplest solution is to create two VMs, one with only 32-bit components and one with only 64-bit components.

Any mix and match is asking for trouble.

Yes, the simplest approach is to use a VM to totally isolate the installations. But that has its disadvantages too.

The simple reality is that we can't mix 32 and 64 bit installations because MS was lazy when it designed Windows and Office installers. MS could have designed both to install 32 and 64 bit applications in totally separate locations. But they didn't.

During the install, there is supposed to be a message showing which applications are in conflict. Of course sometimes that doesn't work.

Try going into the Programs and Features dialog and locate any Microsoft applications. By default MS install 32 bit, so anything you find will most likely be 32 bit.

> MS could have designed both to install 32 and 64 bit applications in totally separate locations.

That is exactly what is accomplished by my VM suggestion.

> MS could have designed both to install 32 and 64 bit applications in totally separate locations.

That is exactly what is accomplished by my VM suggestion.

Sorry, I beg to differ.

Yes using a VM allows what appears to be this sort of installation, but it is not a simple solution.  It requires paying money for VM software, either a more expensive version of Windows, ie Pro, or a 3rd party program (yes there is freeware, but not for business use). And you have to buy a separate Windows license to install inside of the VM. And depending on your VM tool, and how it is setup, you may not be able to share information between applications in the native windows and VM.

All in all, it would have been better if MS had designed Windows to totally isolate 32 and 64 bit application installations, allowing both types to be installed on the computer at the same time, but they didn't.  Don't bother to tell me it's not possible.

> Don't bother to tell me it's not possible

No I won't. Unproductive.

I'm thinking a company of the caliber to have its "our own data-processing engine in 32 and 64 bit form" is probably not without any means and will probably have an MSDN subscription or some other way which includes some server OSes and some client OSes, so Hyper-V is included and can be used to setup the VMs I'm suggesting.