CODEWITHSUNDEEP
c#ms-accessodbcdriver
Ray
Ray

Reputation: 21

How to accommodate both 32 bit and 64 bit odbc drivers

I am writing a c# WPF application, where one of the design requirements is to be able to load data from a Microsoft Access database. I have a variety of questions on this topic related to the MS Access drivers:

  1. If our application is compiled as 64-bit, will it be able to run 32-bit odbc drivers? When I run my application in 64-bit, I get errors when accessing a 32-bit driver and I think I have read somewhere that you can not access 32-bit odbc drivers from a 64 bit application.

  2. If we install 64-bit Access drivers on a client machine and they also have the 32 bit Access drivers already installed, will it mess anything up? By default, Microsoft won't let you install a 64 bit driver if a 32 bit driver already exists. There is a workaround (use /passive command on the install) but I'm afraid that having both drivers might mess up something with Access.

  3. Is there something I am missing? Is there a workaround that other have used to be able to access the correct Odbc driver for their application?

Upvotes: 2

Views: 3131

Answers (1)

Erik A
Erik A

Reputation: 32682

Let's answer this point-by-point:

  1. If our application is compiled as 64-bit, will it be able to run 32-bit odbc drivers?

Nope, it won't.

  1. If we install 64-bit Access drivers on a client machine and they also have the 32 bit Access drivers already installed, will it mess anything up?

Yes, or at least, your mileage may vary here. I've seen people do this and require a full Office uninstall + reinstall to get the Access OLEDB provider working again, and others not having trouble at all. The 32-bit 2010 database engine seems to have less issues than the 2016 one, but not something you want to do in a production application.

  1. Is there something I am missing?

Well, there are lots of alternatives here. For example, you could use a third-party ODBC driver, which doesn't conflict with the default driver, such as mdbtools. You could use the DLL surrogate to spawn a 32-bits COM object and use DAO instead of the ODBC driver to interface with the database. You could provide a 32-bit COM object with the 64-bit application yourself, let that communicate with the ODBC driver, and interface with that using the DLL surrogate. And there are countless more options. None are as polished as just using the ODBC driver, though, and generally, it's common to just provide a 32-bits and a 64-bits build and let the user pick the one matching with their Office install.

Upvotes: 2

Related Questions