|
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.
When I try to connect with the following connect string: dbConn.ConnectionString = "DSN=" & Form1.gsODBC & ";UID=" & Form1.gsLoginName & ";PWD=" & Form1.gsLoginPassE. 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?--
|
|
Let's start from the absolute beginning here..
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? 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 :)
(24 Jun '12, 17:46)
Tharre
3
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.
(25 Jun '12, 09:40)
Chris Keating
|
|
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. |
|
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. |
|
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. 1
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.
(26 Jun '12, 09:22)
Chris Keating
2
In addition to Chris's comment my recommendation would be:
(26 Jun '12, 10:00)
Reimer Pods
1
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.
(26 Jun '12, 11:47)
Ron Emmert
|
|
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 - 2
When a 32-bit program finds and correctly uses 32-bit DS, it is not "weird", it is "works as expected" ;).
(27 Jun '12, 05:20)
Dmitri
2
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.
(27 Jun '12, 09:06)
Chris Keating
2
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.
(02 Jul '12, 23:13)
Tharre
|
Windows Registry Editor Version 5.00
Windows Registry Editor Version 5.00
Please put <pre> and </pre> tags around your code. Thanks!
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.
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
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.