Access 64 bit DSN running 32 bit program

[Former Member]

Well, a few months ago I asked for help and totally got so frustrated I gave up. But, now I really have to try and figure this out. Situation: Accessing a SQL Anywhere 9.0 database System DSN created by a third party software program that is a 32 bit program.

• In the Vb.net program I can interrogate the registry syswow64 and retrieve the ODBC DSN.
• In the odbc64 Data Source Administrator I can see the system dsn.
• I can log on to the database.
• In the task manager the program that is running is odbcad32.exe *32

When I try to connect with the following connect string:

dbConn.ConnectionString = "DSN=" & Form1.gsODBC & ";UID=" & Form1.gsLoginName & ";PWD=" & Form1.gsLoginPass

E. Err: The specified DSN contains an architecture mismatch between driver and application I've tried

dbConn.ConnectionString = {Siebel Database};DSN=SSD Local Db default instance;UID=DBA;PWD=SQL

and it still does not work. So somehow when I do the dbOpen with the connectstring how do I insure that I go against the 64bit odbc directory to connect the same as I do when I'm in the odbc64 Data Source Administrator. Any Clues?--

[Former Member]

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\ODBC\\ODBC.INI\\SSD Local Db default instance]
"Driver"="C:\\\\sea81x\\\\client\\\\bin\\\\dbodbc9.dll"
"DatabaseName"="SiebelLocalDB"
"DatabaseFile"="c:\\\\sea81x\\\\tools\\\\local\\\\sse_data.dbf"
"EngineName"="c__sea81x_tools_local_sse_data_dbf"
"Start"="c:\\\\sea81x\\\\tools\\\\bin\\\\dbeng9.exe -q -m -x NONE -gp 4096 -c40m -ch60m"
"AutoStop"="Yes"
"Charset"="UTF8"
"Description"="Siebel Local Database"

[Former Member]

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\\SOFTWARE\\ODBC\\ODBC.INI\\Siebel Local DB 8.1]
"Driver"="C:\\\\Program Files\\\\Sybase\\\\SQL Anywhere 9\\\\x64\\\\dbodbc9.dll"
"DatabaseFile"="C:\\\\sea81x\\\\tools\\\\LOCAL\\\\sse_data.dbf"
"EngineName"="Siebel Local DB 8.1"
"AutoStop"="Yes"

[Breck_Carter]

Please put <pre> and </pre> tags around your code. Thanks!

[Former Member]

So, I can access the database using the 32 bit odbc entry that I created after installing SQL Anywhere v9.0 and creating an ODBC system entry.

The problem is that my client does not have that ability. I need to use the DSN from the wow6432node directory to be used in the connect string - which I have done. But, when I use the connect string with the dbOpen I get - cannot find the dsn -. So, I feel that the odbc dll I'm using for the dbOpen is not finding the path to the wow6432node.

[Breck_Carter]

FWIW... The following article does mention 32 and 64-bit ODBC with SQL Anywhere Version 9: Using SQL Anywhere on Windows 2003 x64 and Windows XP x64 http://www.sybase.com/detail?id=1054825

[Breck_Carter]

To whoever voted this question down: It was my suggestion that Tharre should start over with a new question... the trail of comments and responses on the previous version was getting just too confusing. Sure, someone (apparently not you!) could spend the time rearranging the original discussion to create a pure and elegant Question and Answer. But Tharre just wants an answer (apparently not from you!) and the best way to get one is to start over. If you (the down-voter) don't like the way this forum works, please [cough] off to Stack Overflow.

[Former Member]

Well after all this and making so many changes to the program went back to the original program and changed the advance compile set it to x86 as suggested and low and behold the program found my 32 bit DSN and program worked.

Thank-you Ron. It's not elegant but I know the vendor will not be changing the database version for sometime.

Chris, Volker and Reimer thank-you too for being patient. Still weird -

[former_SQLA_member1694880]

When a 32-bit program finds and correctly uses 32-bit DS, it is not "weird", it is "works as expected" ;).

[chris_keating]

This is working exactly as expected and designed. An application compiled with 'Any CPU' allows a .NET managed application to be CPU agnostic. This allows applications to be complied once and run on any .NET environment without code changes on x86, x64, or IA64 (Itanium) operating sysems without the need to compile for each of those chips. Your application is not completely managed code as it has dependencies on native client software (the ODBC layer and the ODBC driver). The application must reference the native components in the same bitness that it is running. In the absence of x64 ODBC drivers and DSN for the application, you had to compile it as 32 bit. If you had a 64 drivers, you could have created a 64 bit DSN and the application could run with 'Any CPU'.

The Wow6432Node is "Windows on Windows64 32 bit". It means that it is the 32 bit registry. The same is true for the SysWOW64 which contains 32 bit Windows System files. So, you were correct that was the node to use for 32 bit DSNs but the application was running as 64 bit so was not using that node.

[Former Member]

Thanks for everyone - after reading all the answers and suggestions it totally makes sense. The program's database I'm trying to access is a 32 bit program that is running on a 64 bit machine. Not be a true VB.net programmer but more of a hacker it took me a long time to tie all the pieces together and use that x86 compiler instructions so that the program runs the same as the one that I'm trying to access their SQL Anywhere database.

So, many many thanks to everyone - really appreciate it. It'll be a lesson hard learned but NEVER, EVER forgotten.

Again one more time - thank-you.