Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.

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 = SQL Anywhere 17 driver =

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 =

Test SQL Anywhere 12 database is running on OS = Windows server 2016 standard Windows ODBC version = 10.0.14393.0 SQL Anywhere 12 driver =



asked 28 Nov '17, 08:08

Frank%20Vestjens's gravatar image

Frank Vestjens
accept rate: 21%

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

permanent link

answered 13 Dec '17, 04:36

Frank%20Vestjens's gravatar image

Frank Vestjens
accept rate: 21%

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.


permanent link

answered 28 Nov '17, 08:14

Mark%20Culp's gravatar image

Mark Culp
accept rate: 41%

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

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.

Microsoft did a good job in calling both the 32 and 64 bit ODBC administration tool by the same name: ODBCAD32.EXE, one in the System directory (64), the other ander SysWOW64.

So to solve that puzzle I recommend calling both versions under both user logins and compare them for differences.

(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

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

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 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
showing 4 of 9 show all flat view
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 28 Nov '17, 08:08

question was seen: 3,331 times

last updated: 13 Dec '17, 04:36