Over the years, especially when users and developers migrate from 32-bit to 64-bit office installation, I’ve seen numerous question relating to challenges with setting up ODBC DSN to connect with remote RDMS.
Today, I was hoping to make a short and simple post to demystify this.
ODBC Drivers
The most important aspect of the entire setup to understand is the fact that the ODBC Driver bitness (32 or 64-bit) must match the application using it.
So, for instance, a 32-bit installation of Access requires 32-bit ODBC Drivers, while a 64-bit installation of Access requires 64-bit ODBC drivers be installed.
ODBC Data Source Administrator (DSA)
Obviously, after reading the previous section this should come as no surprise to anyone, you need to use the DSA that corresponds to your application and ODBC Driver bitness.
In other words, for a 32-bit installation of Access using 32-bit ODBC Drivers you would use the ODBC Data Source Administrator (32-bit), while for a 64-bit installation of Access using 64-bit ODBC Drivers you would use the ODBC Data Source Administrator (64-bit).
So pay attention when you are launching the ODBC Data Source Administrator to be sure to launch the proper one as both are present on your PC.
The ODBC Data Source Administrator (32-bit) is located under:
C:\Windows\SysWOW64\odbcad32.exe
while the ODBC Data Source Administrator (64-bit) is located under:
C:\Windows\System32\odbcad32.exe
You’d think Microsoft would have distinguished the filenames. Instead they have the term ’32’ even in the 64-bit version of the DSA executable. Add to that they place the 32-bit version in the SysWOW64 folder and the 64-bit version in the System32 folder.
It doesn’t get much more messed up then that!
So you just have to know the difference and live with the Microsoft reality of things where common sense goes out the window (no pun intended).
You should also easily be able to launch them by simply entering “ODBC” in the Windows search and then selecting the appropriate bitness (as explained above).
Visual Studio
Visual Studio can also be impacted by the same bitness issue and can generate messages like:
It is important to note that in Visual Studio:
This is because the default build settings for .NET Framework projects have the “Prefer 32-bit” checkbox checked (go to your project properties, then go to the build tab, and you’ll see that checkbox already checked).
Once you start targeting later versions of .NET (.NET Core, like .NET 8.0 or whatever), then “Any CPU” will default to running as 64-bit on new projects.
You can easily check this by creating a blank .NET Framework 4.8 app, and a blank .NET Framework 8.0 app. By default they should both be set to target “Any CPU”, so run both of them and switch over to the Details tab in the Windows Task Manager, and add the “Architecture” column to the layout.
You’ll see the .NET 4.8 (Framework) app’s architecture will be x86 (32-bit), while the .NET 8.0 (Core) app’s architecture will be x64 (64-bit).
If you installed the 64-bit Access driver and you don’t need your app to run on 32-bit operating systems, just change the target type of your app to be x64 or uncheck the “Prefer 32-bit” checkbox in the Build properties.gr8gonzo
It’s that simple, once you know. So to recap, what matters is the bitness of the application using the ODBC drivers, not the bitness of the database being accessed!
Page History
| Date | Summary of Changes |
|---|---|
| 2025-03-17 | Initial Release |
| 2025-03-18 | Added the Visual Studio section |