8

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?

Hadi
  • 36,233
  • 13
  • 65
  • 124
Jarrod Christman
  • 380
  • 2
  • 19
  • [This](https://stackoverflow.com/a/12537390/6305294) should help even though it is from Java perspactive – Alex Nov 09 '17 at 07:35
  • Yeah, that is what I found in my searches. However that is for the ODBC utility for setting up DSN connections. What I'm trying to achieve is a DSN-less connection, meaning I can bypass that utility entirely. My connection string in the post works, but doesn't seem to allow me to specify the bit level, in this case, 32 bit. – Jarrod Christman Nov 09 '17 at 13:44
  • Here is an article discussing DSN-less connection strings: https://www.databasejournal.com/features/mssql/article.php/1491011/ODBC-DSN-Less-Connection-Tutorial.htm – Jarrod Christman Nov 09 '17 at 13:46
  • @JarrodChristman, the DSN-less connection string doesn't need to change for 32/64 bit; the appropriate ODBC architecture should be used be used automatically. I can reproduce arch mismatch error only with a DSN connection (e.g. 64-bit DSN and x86 app). Are you using `System.Data.Odbc`, `ADODB`, or something else? In the case of ADODB, what version of ActiveX? – Dan Guzman Nov 12 '17 at 15:23
  • I am using the string as mentioned in the post. The program is using System.Data.Odbc. It is opening a new connection the standard way by passing the connection string to the constructor New OdbcConnection([connection string (stored in settings)]). If I go to a computer that has a previous DSN setup for the application and the OS is 64 bit, I get that error. Since the new connection string makes no mention of the old DSN, I wouldn't think that would matter. There are other applications that make use of the old DSN so I don't want to remove it entirely. – Jarrod Christman Nov 13 '17 at 16:19
  • 1
    Just make sure you never install the 64bit driver version. – Namphibian Nov 13 '17 at 20:20
  • Just to echo @Namphibian, are you sure the 32bit version is installed and not the 64bit version only? I use 32bit versions of ODBC drivers all the time and my OS is 64bit. – Beth Nov 14 '17 at 22:09
  • I appreciate the help but read my comments to Hadi. – Jarrod Christman Nov 14 '17 at 23:04
  • I coudn't replicate it. Built 4 times with different options (target=x64, target=x32, target=anycpu, target=anycpu + "Prefer 32 bit"). All 4 work fine – Andrey Belykh Nov 17 '17 at 15:51

1 Answers1

3

"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

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

Hadi
  • 36,233
  • 13
  • 65
  • 124
  • 3
    Thank you, but I think people aren’t understanding this is for a DSN-less connection. Meaning I pass the connection string directly to .NET’s ODBC and bypass entirely the odbc configuration tools you’re talking about. Likewise, in this DSN-less connection string I am referencing the pre-installed 32 bit AND 64 bit SQL Server ODBC driver. Hence my issue. It’s not a matter of what tool to use for the configuration nor what driver to install (as both bit versions are installed by Windows by default). – Jarrod Christman Nov 14 '17 at 23:00
  • 3
    Keep my in mind if I do use a DSN based connection string it all works fine. Actually if I have two DSN’s with the same name and a 32 and 64 bit version, the DSN based connection string picks the correct one automatically. What I am going for those is where the connection string bypasses any DSN and is entirely self contained. – Jarrod Christman Nov 14 '17 at 23:03
  • 1
    The idea with this is it’s a lot easier to deploy such a program since the exe only resides in one location across the organization. – Jarrod Christman Nov 14 '17 at 23:05
  • @JarrodChristman in the project properties window, 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 – Hadi Nov 15 '17 at 09:14
  • @JarrodChristman also you can take a look at https://stackoverflow.com/questions/8895823/the-specified-dsn-contains-an-architecture-mismatch-between-the-driver-and-appli there are many answer that may give you some ideas – Hadi Nov 15 '17 at 09:17
  • @JarrodChristman this type of connection is very old, it is related to VB6, i couldn't find article concerning it. If the effort needed to replace them with `SqlConnection` found in `System.Data.SqlClient` is not big. it is recommended to do it. I am sorry that i couldn't help. Best regards – Hadi Nov 15 '17 at 17:52