Using 32 bit ODBC driver in x64?

I'm trying to use a 32 bit ODBC driver (PostgreSQL) under Win XP Pro x64.
I've installed the driver, but can't get it to appear in the Data Sources
applet. I've learned from searching around that I should run odbcad32 to get
32 bit drivers to show up, but this doesn't seem to solve the problem.

Can anyone give me any pointers on how to install/use a 32 bit ODBC driver
under x64?

Yes, you can use 32-bit ODBC.

It's important to understand which kind of DSN you have. On an x64 system,
you can create an ODBC connection(DSN) on the 32-bit side of the system or
on the 64-bit side of the system.

32-bit applications will only see ODBC connections created in the 32-bit
side, and 64-bits applications will only see ODBC connections from the
64-bit side. Each kind of application has is own registry.

To setup DSN for 32-bit application you must use:
%WINDIR%\SysWOW64\odbcad32.exe
and for 64-bit application you must use:
%WINDIR%\System32\odbcad32.exe

've got a 32 bit DSN created and can test it
from the ODBC Admin program and it connects to the database without problem.
Unfortunately I'm still unable to make the same connection from my 32 bit c#
exe file. It throws an error complaining that the DSN was not found.

I have C++ application 32 bit application which uses a connection string to
access an oracle database.

The connection string looks like this
driver={Microsoft ODBC for Oracle};server=Dbname;pwd=xxxxx

Since the microsoft driver doesnot exist in the 64bit ODBC admin, how can I
tell the system to look into the WowSys64 directory.

You need to make sure it calls into the 32-bit version. I'm not a C#
developer, heck I'm not even a C developer any more. But I suspect it has to
do with the pathing. You may need to explicitly enforce SysWOW64 in front of
system 32 on the path for the duration of your program. And if that's not
it, think about other reasons why a 64-bit version would be called before a
32-bit one.

Probably by putting the SysWOW64 directory ahead of the system32 directory
for the duration of the 32-bit program. But honestly, this is something that
Oracle should correct. I'd post something on their forum if I were you.

[eduardofernandes]

I´m facing the same problem. I have an application that runs perfectly on x86 machines, but on windows 2003 server it just can´t find the postgresql driver on odbc.
By, Syswow32\odbcad32.exe I could add the connection but my application (c#) still can´t find it.

I've been struggling with this for quite a few hours. First you must use the C:\Windows\SYSWOW64\odbcad32.exe administrator console to setup the DSN which most people have already posted.

HOWEVER, you must also do the following in your application: in Visual Studio, go to the "Build" page from the Project properies window. Under the "General" section, change the setting in the "Platform target" drop-down box to "x86".

This worked for my C# app in VS 2008.

I'm trying to do the same as the message below: connect through Access 2007 using ODBC on a Windows Vista 64 bit machine. I can connect using SQL Plus but not through ODBC in Access. I've tested both sides and the test connection comes back fine. How do I redirect the application to look for the 32 bit as you stated below?? I'm not quite following your directions and I don't want to mess the registry up, can you give me some more clarification on how to do this?

To make an ODBC DSN that 32-bit apps can use, you need to use the 32-bit
ODBCadmin, which is in \windows\syswow64. The one in \windowsy\system32
is for 64-bit DSNs. I know that sounds backwards, but it's not...

[ImEmmittSmith]

I ran into this same problem with having a 32 bit application that needed to run on a x64 Server. I unregistered the database from the x64 ODBC and then registered the database using the x86 ODBC driver. Does anyone know if there would be a degration of performance when others connect to the server and the server is now using the x86 ODBC driver over the x64 ODBC driver? Wonder why MS did not name it odbcad64.exe? Sure would have made using ODBC for x86 and X64 applications more understandable!

[EINSTEIN_007]

One of the performance benefits of the x64 platform is that it increases virtual address space, making more memory available. We recommend that you configure IIS to use a 32-bit worker processes on 64-bit Windows. Not only its compatibility better than the native 64-bit, performance and memory consumption are also better.

Set the Web server to enable this globally so that you do not need to set it for each application pool. Unlike previous versions of IIS, you can now configure specific worker processes to run in 32-bit or 64-bit mode independently of each other on the same server.

To configure 32-bit mode for the server

•Open a command prompt and run the following:
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.enable32BitAppOnWin64:true
Note: This setting applies only to 64-bit servers.

To configure 32-bit mode for the server using the IIS PowerShell Provider

•Open a PowerShell prompt and run the following:
set-itemproperty iis:\ -name applicationPoolDefaults.enable32BitAppOnWin64 -value true

No, there wouldn't be (indeed, it's arguably a massive improvement,
since the x64 ODBC driver doesn't work!).

For compatibility. Applications looking to invoke the ODBC
administrator all start "odbcad32.exe", and that's true whether they're
x64 or x32.

What would have been helpful is putting both versions in Administrative
Tools, clearly labelled.

[ImEmmittSmith]

Hey Einstein_007,
thanks for the reply and that sounds like a great option, but different than what I was trying to determine or I may not be totally understanding your suggestion. What I was talking specificially about was the X86 vs X64 ODBC drivers themselves. Since I unregistered the database from the X64 ODBC driver and registered it using the X86, what type of performance concerns should I be aware of, if any. We just moved to a Windows 2008 Server X64 to enable DB2 UDB 9.5 to utilize more memory, which was a HUGE constraint under Windows 2003 X86.

Thanks,
Don

[ImEmmittSmith]

Steve,
I echo you sentiment, they should have put both in Admin Tools and labeled them as such. I spoke with one of the lead network admins where I work and he said there would be no issues using the X86 ODBC.

Thanks for everyone's help in clarifying this issue.

E