0

I have a VB.net application that I am trying to upgrade to use the corporate-mandated 64 bit Access .accdb data source. I have tried installing 32 bit AccessDatabaseEngine.exe, but it won't install because there is a full 64 bit Office installation on the machine. The .Net app will not connect to a 64 bit ODBC DSN or to the ACE.OLEDB provider (says it's not registered). I have been unsuccessful in compiling this app as a x64 app due to some custom 32 bit .DLLs that are included.

Is there a way to get a 32 bit .Net app to use a 64 bit Access data source?

Barry
  • 63
  • 7
  • 1
    Does this answer your question? [Hand Install of 64-bit MS Access ODBC drivers when 32-bit Office is present](https://stackoverflow.com/questions/7116019/hand-install-of-64-bit-ms-access-odbc-drivers-when-32-bit-office-is-present) – Erik A Nov 18 '19 at 15:48
  • It's the same for installing the 32-bit ODBC driver with the 64-bit system. There's no way to use the 64-bit driver from the 64-bit app. – Erik A Nov 18 '19 at 15:50
  • 1
    Does you app really need to be 32-bit? -- There's no Access 64/32 bit format, the file is the same no matter what version of Office is installed. If your app must be 32-bit, for some reason, you have 2 Providers: `Microsoft.ACE.OLEDB.12.0` and `Microsoft.ACE.OLEDB.16.0`. See what provider is installed and install the 32-bit version of the other. – Jimi Nov 18 '19 at 16:03
  • 1
    There is an alternative if you must have cross-bitness between your app and the Access driver: Write an out-of-process COM server with the same bitness as the Access driver, and use the out-of-process server to talk to the database. (The COM server can be written in VB.NET, there is Microsoft sample code for it around somewhere.) – Craig Nov 21 '19 at 22:36

1 Answers1

2

You have to force you .net project to x64 bits if the ACE x64 data engine is to be used. In .net, if you choose "any CPU" then in most cases, you get a x32 bit in-process. And since Visual Studio is x32 bits, then a setting of ANY CPU or x86 will always result in a x32 bit running process.

Now if you choose ANY CPU and some other windows process running as x64 attempts to use that assemply, then .net will consume and launch that .net project or .dll as a in-process x64 process.

However, since your starting your .net program first, then you have to force it to run as x64 bits, and it should work just fine.

Since the dawn of the personal computer age, you never been able to mix a different bit size program to talk to another program running as a different bit size program. This is especilly the case with in-process consuming of .dll's. If you going to use ACE x64 with .net, then you simply need to ensure and force your project to always run as x64 bits. So set the project settings to x64, and don't use x32, or use ANY CPU. Any CPU in most cases will wind up starting as a x32 bit process. Also, while in Visual Studio you can use the various connection string builders to setup a connection to ACE, but if you hit "test connetion", it will not work since VS is a x32 bit application. So to actually test if you can connect, you have to run the program, since the "test connection" in the VS builders run as x32 bits during the development process.

Albert D. Kallal
  • 42,205
  • 3
  • 34
  • 51