cancel
Showing results for 
Search instead for 
Did you mean: 

Access 64 bit DSN running 32 bit program

Former Member
12,947

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?--

Accepted Solutions (0)

Answers (5)

Answers (5)

Former Member

We also use a mix of 32/64 bit clients on 64 bit machines. There are a couple pragmatic solutions we tend to use that work. If you have control over the DSN setup, machine config, and SA install, they work well enough. If you must work with existing settings and you end up with a mix of clients, there is probably no substitute for understanding what config is stored where. (this always helps anyway)

Solution 1: Compile everything to 32 bit. Unpalatable, but effective for the short term.

Solution 2: Install both 32 bit and 64 bit client access when installing SA and always use User Data Source setup. The following link notes "On 64-bit Windows, there is only one registry entry for User Data Sources". There is also a caveat about not including full path names for the driver name, but I've never had to worry about that under SA 12. http://dcx.sybase.com/index.html#1201/en/dbprogramming/connection-information-client-deploy.html

Solution 3: Again install both 32 bit and 64 bit SA client access. Create 2 System Data Sources with the same name and connection information; one is 32 bit, the other 64 bit. It gets confusing if you ever need to change the information since it must be changed both places, but it works.

Note that another answer has some important information on which ODBC config you are running.

Former Member

Let's start from the absolute beginning here..

  1. C:\\Windows\\SysWow64\\odbcad32.exe - This is the 32bit ODBC Administrator
  2. [HKLM]\\Software\\Wow6432Node - This is the 32bit section
  3. The ODBC Administration dialog you launch from the administrative tools section of the control panel is the 64bit version.
  4. Do not open the 64bit ODBC Administrator AND the 32bit ODBC Administrator at the same time. They get confused. Close one before you open another.
  5. If the original application is 32-bit, then the ODBC it creates/uses will be 32-bit. If you NEED 64bit, you'll have to create it/manage it.

With all that being said, what is the targeted CPU architecture of the application you're building from the properties dialog of your VB project? Will you be deploying ONLY to 64bit machines, or to 32bit as well?

Former Member
0 Kudos

Thank-you both Breck and Calvin. The VB project is currently working great in XP but with the rest of my co-workers starting to get W7 64bit OS it has becoming very important to be able to convert this program to access the wow6432node as the program we install places the ODBC there. We do not have access to a 32 bit SQL Anywhere 9.0 client as this has worked. I have a personal developer version that I have successfully gotten to work on a 64 bit machine with the 32 bit ODBC DSN that I created. But my co-workers do not have that functionality.

I will keep the 32bit VB program and create a 64 bit program if that is what it takes. I'm sure I have the wrong ADO.net program in my project or something silly like that.

I have successfully walked the registry to get the DSNs from the wow6432node directory but when I use them the dbOpen function does not find the DSN as I'm sure it is looking at the 32Bit ODBC directory.

BTW - this is my first foray into 64 bit programming so be kind 🙂

chris_keating
Product and Topic Expert
Product and Topic Expert

You do understand that Windows manages access to the 32 bit layer by 32 bit applications on Windows 64 without any action needed by the application developer? And you should not within an application directly access the registry layer at Wow6432Node. The OS handles the redirection to the correct node depending on the application bitness.

A VB.Net (or C# ) application by default runs in the same bitness as the Operating System generally. If you are compiling your VB.Net code with 'Any CPU' as the platform, the software will be running as 64 bit on the Windows 7 platform and 32 bit on the XP platform. You cannot use a 32 bit driver with a 64 bit application.

Is the Vb.Net application is compiled with 'Any CPU'? If so, it will run the same bitness as the platform. If you need it to be 32 bit only, you must explicitly compile the application that way.

Why do you think you need to reference a 32 bit DSN? That should be using a 32 bit driver and that will not work with a 64 bit application. Again, you must ensure that you application is running as a 32 bit application to use the 32 bit driver.

VolkerBarth
Contributor

I would simply make sure that your ODBC DSN installer and your app use the same bitness - then you can leave all the detailed knowledge over Wow6432 nodes behind, as Reimer has already suggested...

Possibly you may make use of the DBDSN utility to create/maintain SQL Anywhere ODBC DSNs. On 64 bit systems, it is available both as 32-bit and 64-bit program, so it's easy to create an according user or system DSN with the appropriate bitness.

Former Member
0 Kudos

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 -

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

chris_keating
Product and Topic Expert
Product and Topic Expert

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.

Former Member
0 Kudos

I'll add a piece of information that may help. I'm writing a third party software to a package that runs Sql Anywhere 9.0 and places the

odbc dsn in the wow6432node registry entry. When the install of the program is on a 32 bit machine my database open call works fine. It's when the program is installed on a 64 bit os as the install put the odbc dsn in that wow6432node directory.

I have succesfully retrieved the dsn from the wow6432node and placed it in the connect string. When I use that connect string in the databse open call the message is something like DSN not found as my database open seems to be looking at the 32 bit odbc dsn.

So, I guess my problem is that I cannot open the sql anywhere database 9.0 in VB.net. I wonder if there is a flag or setting in the vb.net that will point to the wow6432node driver.

thanks again - everyone is being very helpful.

chris_keating
Product and Topic Expert
Product and Topic Expert

The wow6432node is the 32 bit registry hive. So, a 32 bit application will, without developer interaction, when needing to access the registry look in this node. The operating system handles this for you.

Again, how are you compiling the VB.Net application. If you are using 'Any CPU', it will be running as 64 bit code on a 64 bit OS. Based on the behavior you describe, this appears to be the issue. For grins, create a 64 bit USER DSN of the same name and see if the application still reports the error you are seeing.If the error goes away, the application is running as 64 bit - and as such will need a 64 bit DSN.

reimer_pods
Participant

In addition to Chris's comment my recommendation would be:
pretend you've never head about Wow6432Node, create the 2 ODBC data sources fpr 32 and 64 bit and let Windows handle the rest.
If your program will still not connect we need to get into the details of how you configure the connection in your source/project.

Former Member

Since you know the target DSN is 32-bit, when retrieving the connection information you need to know what your process is running as.

If you target it for "x86" instead of "Any CPU" to make it 32 bit, you don't even need to worry about wow6432node.

Otherwise check Environment.Is64BitProcess. If your process is running 64 bit look under the wow6432node hive. If not, it is 32 bit and you can look under the normal hive for the connection information.