|
When trying to run the following statement in the command prompt: dbisql.exe -c "dsn=transfusion;uid=...;pwd=..." I get the following error: The specified DSN contains an architecture mismatch between the Driver and Application [IM014] I did this because our application won't start and the window of the ODBC popsup to enter the correct credentials which are already filled and are correct. If we run this under the domain administrator account everything is working fine. If we use a normal user account I get the error. If I add the user to the domain user account everything is working fine. Where should we look to solve this issue because I don't want the user to be a domain user account When we start the application in a session as domain administrator on the server then the users can login and are able to access the database in our application. If the our application is not started users get the windows odbc logon screen. Also tried to add the IP number and the port number in the odbc setting without any success. Firewall is disabled and virus scanner has been removed. We're running the test environment on a SAP SQL anywhere 12 database machine on windows server 2016 standard. We have the same problems there as well. We both tried to connect through the SQL Anywhere 12 and the SQL Anywhere 17 odbc driver without any difference. Application for both test and production is running on OS = Windows server 2016 standard Windows ODBC version = 10.0.14393.0 SQL Anywhere 12 driver = 12.00.01.4436 SQL Anywhere 17 driver = 10.00.00.1062 Production SQL Anywhere 12 database is running on OS = Windows 2003 server standard edition 5.2.3790 Service Pack 2 Build 3790 Windows ODBC version = 3.526.3959.0 SQL Anywhere 12 driver = 12.00.01.3873 Test SQL Anywhere 12 database is running on OS = Windows server 2016 standard Windows ODBC version = 10.0.14393.0 SQL Anywhere 12 driver = 12.00.01.4436 TIA Frank |
|
The cause was calling the application using UNC path in stead of a mapped drive letter. For some reason that does something weird with our application and the way ODBC is started |
|
After a bit of googling for the specific error "architecture mismatch between the Driver and Application [IM014]", the responses leads me to believe that the issue is related to the bitness of your DSN/driver and the application. I.e. a mismatch between the bitness of the driver and your application. Make sure that you have created the DSN using the same bitness - either 32 or 64 bit - as your application. HTH That's what I've found as well. But that's why I used dbisql.exe to see whether that would be the difference. I'm using the same dbisql.exe under the domain account and the user account and still it fails under the user account.
(28 Nov '17, 08:23)
Frank Vestjens
1
Make sure you understand the differences between a User DSN and a System DSN. If a User DSN is defined under the admin account, it won't be usable for users with another login. To add more confusion, two DSNs with identical name, but different bitness can happily coexist.
(28 Nov '17, 10:56)
Reimer Pods
Replies hidden
AFAIK, it's even more cumbersome: On 64-bit systems, a system DSN ist either 32 bit or 64 bit whereas an user DSN ist "magically" provided in both bitnesses. So when using a system DSN, I always make sure it ist created with fitting properties in both bitnesses...
(28 Nov '17, 11:07)
Volker Barth
1
This is a bitness mismatch but the question is why. I suspect a problem with the ODBC configuration. I would compare the content of ODBC Admin tool (32 bit and 64 bit) for both accounts and see if there are differences for the DSN that is problematic. Make sure to do a test connection for each "transfusion" DSN that is defined. My initial guess was a conflict between USER and SYSTEM DSNs but that would likely not be resolved by adding an user to a domain account. You may have to drill into the registry to get to the bottom of this if the GUI is not helpful. What bitness is the application?
(28 Nov '17, 11:42)
Chris Keating
Replies hidden
FWIW, I usually get that exact message when using DBISQL (64 bit) with a 32 bit system DSN, when there is no according 64 bit system DSN and no user DSN with that name. Applications do work as they are still 32 bit...
(28 Nov '17, 15:03)
Volker Barth
The application is 32-bit. the driver tracing in the ODBC driver shows the following error: tfmain 483c-202c EXIT SQLDriverConnectW with return code 100 (SQL_NO_DATA_FOUND) HDBC 0x008B7870 HWND 0x00010010 WCHAR * 0x64FF2220 [ -3] "**\ 0" SWORD -3 WCHAR * 0x64FF2220 SWORD -3 SWORD * 0x00000000 UWORD 3 <sql_driver_complete_required>
(30 Nov '17, 08:29)
Frank Vestjens
What we do now is we logon to the system as administrator. Then start our application and then the users are able to start the application as well in their session.
(30 Nov '17, 08:32)
Frank Vestjens
And what kind of DSN (User vs. System) do you use?
(30 Nov '17, 10:48)
Volker Barth
1
Volker asked if the DSN is a System DSN or a User DSN. To troubleshoot this issue, I would really want to dig into the registry on a problem machine to see the ODBC configuration for both accounts and for both the 32 bit (WOW64) and 64 bit tiers in the registry. My guess is that there is a DSN of a different bitness than the application that is taking precedence. You have indicated that one account works while another fails. This suggests that there is an USER DSN (which is specific to the current user logged in) that is the problem. A System DSN is global to all users on a machine so if the problem was in the System DSN all users would be impacted. The registry nodes of interest: HKEY_LOCAL_MACHINE\SOFTWARE\ODBC (64 bit SYSTEM DSNs) HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ODBC (32 bit SYSTEM DSNs) HKEY_CURRENT_USER\SOFTWARE\ODBC (64 bit USER DSNs) HKEY_CURRENT_USER\SOFTWARE\WOW6432Node\ODBC (32 bit USER DSNs) The 32 bit USER DSNs node in the registry may not exist on some operating systems. What to look out for is USER and SYSTEM DSNs with the same name that are configured differently and more so if that is the case in for DSNs with different bitness of the underlying ODBC driver.
(30 Nov '17, 15:11)
Chris Keating
|
