SQL Server DSN-Less ODBC Specify 32 bit Driver

Question

I'm working with an older application that I recently updated to .NET 4.5. The application has been using DSN ODBC connections. However, in the case of the application, it is accessed from a single location on a network drive, so it doesn't make sense to require a DSN, and it will ease deployment and updates to use a DSN-less connection string in place. I'm doing a basic string as such:

Driver={SQL Server}; Server=; Database=; UID=; PWD=

The issue I have is that the application is compiled as 32 bit, but may be used on a 32 bit or 64 bit machine. On 64 bit machines I get this error:

The specified DSN contains an architecture mismatch between the Driver and Application

Which essentially means it's trying to use the 64 bit driver for the 32 bit application. That's easy enough to deal with except the driver name for SQL Server appears to be the same for 32 and 64 bit. So how can I specify only the 32 bit driver in the connection string?

Answer 1

"To manage a data source that connects to a 32-bit driver under 64-bit platform, use c:\windows\sysWOW64\odbcad32.exe. To manage a data source that connects to a 64-bit driver, use c:\windows\system32\odbcad32.exe. In Administrative Tools on a 64-bit Windows 8 operating system, there are icons for both the 32-bit and 64-bit ODBC Data Source Administrator dialog box. Read more"

If you use the 64-bit odbcad32.exe to configure or remove a DSN that connects to a 32-bit driver, you will receive the following error message:

The specified DSN contains an architecture mismatch between the Driver and Application

To resolve this error, use the 32-bit odbcad32.exe to configure or remove the DSN.

References

• The specified DSN contains an architecture mismatch between the Driver and Application
• Managing Data Sources

---

Side Note: make sure that all references Copy Local property is set to True, even the System assemblies. I think that the issue may be from the assemblies location saved in GAC, so when copying the assemblies locally it may fix that