The switch to 64 bit was an essential step for computing; however, the bliss of having the extra addressing space was not all that we got unfortunately. The mixture of 32 bit and 64 bit environments has been a source of headaches for quite a while as demonstrated by the popularity of my other post on the subject regarding accessing 32 bit com objects from 64 bit processes.

Recently I was working on a PHP script and I wanted to access my Microsoft SQL database. So I created a system DSN for the database I wanted to access but while testing the DSN itself was successful my PHP script refused to even acknowledge the DSN existence.

As expected, it turns out the problem was the usual 32 bit and 64 bit interaction issue. When you access Data Sources (ODBC) under Administrative Tools in a 64 bit Windows Operating system the 64 bit version of the client (odbcad32.exe) will be loaded. This will create the DSN which will be accessible by 64 bit applications only.

To create a DSN that is accessible by 32 bit application we need to use the 32bit version of the Data sources (ODBC) client. The executable is named the same, however it is located in the path: %windir%\SysWOW64\odbcad32.exe instead of %windir%\System32\odbcad32.exe where the 64 bit client resides.

Once the DSN is created using the 32bit version of the odbcad32.exe client your 32bit application should be able to access the newly generated DSN.

Get your free 30-day GFI LanGuard trial

Get immediate results. Identify where you’re vulnerable with your first scan on your first day of a 30-day trial. Take the necessary steps to fix all issues.