architecture mismatch for sybase central 6 connecting tosql 11 using odbc

[g_g_99]

I got architecture mismatch using odbc profile xxxx on sybase central

Connection failed.

[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application

however I can use the use DSN xxxx 64 bit sql anywhere 11 driver in odbc data source admin 64 bit

prior to migration I was able to coonect sybase central with the same odbc profile or dsn

how do I avoid the mismatch

[Breck_Carter]

It's probably a 32-bit-versus-64-bit issue. Tell us more about the software in use; what bit-ness of the SQL Anywhere server (32 versus 64), what version and bit-ness of the ODBC driver, what bit-ness of Sybase Central.

You might also find ideas in other discussions of this symptom (which folks seem to have with V9 mostly).

[chris_keating]

It is complicated enough to get your mind wrapped around the bitness for system32 and syswow64. Now, DSNs are visible in both 32 bit and 64 bit ODBC Administrators regardless of the driver bitness when defined. And further complicated in that you can define a 32 bit USER DSN and it magically is able to be both 32 and 64 bit while SYSTEM DSNs are only the bitness in which it is created.

Make sure that you check the bitness of the DSN in the ODBC Administrator using the platform column. It will need to be the same bitness as the application - you should check also that you can connect/configure the DSN in the ODBC Administrator bitness that matches your application - the Remote and Configure buttons will be disabled if the DSN bitness differs from the ODBC Administrator.

[g_g_99]

thank you for replying. the odbc admin sql anywhere11 is on 64 bit platform. the platform is windows 10 Pro x64 running on the i7 processor. in ODBC I can test connection successfully with both 32 bit and 64 bit engine in the start line.

ODBC sql anywhere 11 version is 11.00.01.2860. ODBC core Compoenents are of V 10.0.17134.1

is it possible to connect Sybase central without using ODBC?

[Breck_Carter]

It might not make any difference, but you can connect to a database from Sybase Central without using a DSN.

On the "Identification" tab of Sybase Central 6 (SQL Anywhere 11) "Edit Connection Profile" dialog box, click "None" in the box "You can use default connection values stored in a profile."

Then go to the "Database" tab and fill in the "Server name:" and "Database Name:" fields; e.g., ddd11 in both if the database file ddd11.db was started without any overriding -n different-name options.

I don't know if Sybase Central still uses ODBC, and if it does, where it gets the "Driver" value... but that's redundant... I don't know anything about Sybase Central 🙂

...and, apparently, I know less than I thought about ODBC bitness, given Chris Keating's frightening comment 🙂

[VolkerBarth]

what bit-ness of Sybase Central

That question is still unanswered. SC needs the ODBC DSN to be of the same bitness, or to use a USER DSN (because those are shared between 32 nd 64 bit processes, as Chris has pointed out).

I agree that the situation might sound difficult but once the bitness requirements are cleared, is easy to solve the issue:)

[VolkerBarth]

OK, AFAIK, the Java-based admin tools for SQL Anywhere 11.0.1 are 32-bit only on Windows. 64-bit tools were introduced with v12.

Resume: If you want to use a system DSN with SQL Anywhere 11 Sybase Central, make sure it setup for 32-bit ODBC...

[Breck_Carter]

FWIW I was able to run the 32-bit V11 Sybase Central 6 on Windows 10 to successfully connect to a 64-bit V11 SQL Anywhere database on the same computer by using a DSN-less connection as described earlier... either (a) it was able to find the Magic Unicorn Path through the forest of ODBC bit-ness or (b) it didn't use ODBC. IMO DSNs suck and should be avoided whenever possible 🙂

[g_g_99]

thank you , Volker. sybase central is 32 bit unfortunately. I just couldn't get the 32 bit SA driver to show up in odbc admin. Below were my failed attempts to get the 32 bit driver to show up the odbc admin:

after repairing sql anywhere 11 with "SA11_Full_Win32+x64.1101_2960_EBF.exe" i now see sa 11 (dbodbc11.dll)in the driver list of the odbc 64 admin but not in the 32 bit odbc 32 admin. the date of the driver in the list is 2013-03-25. no size given I do find dbodbc11.dll in bin32 and bin64 of the SA installed directory. since the bitness is 64 in the user dsn list, I can only say it's x64 driver.

Normally I would say repair or re-install but I tried those already. the next step is to look for the registry. however I found only ODBC32 and ODBC64 in the sql anywhere key Computer\\HKEY_CLASSES_ROOT\\Installer\\Features\\0B362ECEB8C6C4044BCAF8BAC178BAA4.

as for the rege key Computer\\HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\ODBC they are basically empty no mention of dbodbc11.dll anywhere in regedit what else can I do?

[chris_keating]

Sybase Central (SC) is not using ODBC for its connections. The DSN is user simply as a source of connection parameters to make a connection. My recommendation is to skip the DSN and use the "Connection Profiles" feature if you are able to connect in SC without using the DSN.

The definitive list of DSNs that are matched bitness is available by clicking Browse in the SC connection dialog. If you do not find the DSN that you are currently using it that list, it cannot be used for supplying connection information as it is not a valid bitness.

I suspect that the DSN has supplied manually (not by selecting it from the Browse list) or the DSN name was cached from an earlier connection but that DSN is no longer defined for the given bitness.

Alternatively, the registry was modified incorrectly. Someone familiar with the ODBC registry setup should be able to determine if the registry is valid. For 32 bit registry, you need to look via the

HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node

and ensure that "SQL Anywhere 11" is defined (correctly) here

HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\ODBC\\ODBCINST.INI\\SQL Anywhere 11

and that it is marked as installed here

HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\ODBC\\ODBCINST.INI\\ODBC Drivers

[g_g_99]

thanks to Kris for getting to the solution with regedit in admin mode on the wow6432 node.

got it working.

for what is worth to other, below is the modification

HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\ODBC\\ODBCINST.INI\\SQL Anywhere 11

Driver    REG_EXPAND_SZ    %ProgramFiles%\\SQL Anywhere 11\\Bin32\\dbodbc11.dll

Setup    REG_EXPAND_SZ    %ProgramFiles%\\SQL Anywhere 11\\Bin32\\dbodbc11.dll

DriverODBCVer    REG_SZ    11.00.01.2960

also added "HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\ODBC\\ODBCINST.INI\\ODBC Drivers" SQL Anywhere 11 REG_SZ Installed

---

however in odbc admin 32 show the driver SQL Anywhere 11 version and Company as "Not Marked" and has no Date value

good news is there the bitness of my sa 11 user Dsn for myDb as 32/64-bit and allowed to connect with the original user DSN

Note I discovered that only the two reg_Sz for Driver and Setup are required as demostrated by another non microsoft odbc driver. Furthermore the value (Default) Reg_sz must be empty resulting display of *Value not set) that non MS odbc driver also show that the Driver and Setup values could have been hard coded with reg_sz type and will allow successful connection

[VolkerBarth]

Hm, there really should not be need to modify the registry manually...

The 32-bit driver should be registered fine via

%WINDIR%\\SysWOW64\\regsvr32.exe "%SQLANY11%\\bin32\\dbodbc11.dll"

and the 64-bit driver via

%WINDIR%\\System32\\regsvr32.exe "%SQLANY11%\\bin64\\dbodbc11.dll"

[g_g_99]

thx, Voker, I'll keep that in mind using regsrv next time around instead of manually editing the register

[Vlad]

I don't remember that I had to use two different regsvr32.exe files to register the drivers. I have checked this URL, it says nothing about this fact: http://dcx.sap.com/sa160/en/dbprogramming/configuring-driver-client-deploy.html

[VolkerBarth]

Yes, since quite some time both regsvr32.exe executables seem to check the bitness of the DLL to register and then start "the other" regsvr32.exe when the DLL's bitness is different from their own. Cf. that SO FAQ.

However, when dealing with bitness issues, I still think it's easier to separate "both worlds" strictly - simply because regsvr32.exe handles bitness "automagically" but odbcad32.exe and many other applications do not.