Why my 32 bit applications cannot see the ODBC DSNs that I created on my 64 bit machine ?


As we all database developers know that a ODBC DSN is an entry that we created through “ODBC Data Source Administrator” that we reached from Start/Control Panel/AdministrativeTools  or typing “odbcad32” from Start/Run .

On a 64bit machine when you run “ODBC Data Source Administrator” and created an ODBC DSN, actually you are creating an ODBC DSN which can be reachable by 64 bit applications only.

But what if you need to run your 32bit application on a 64 bit machine ? The answer is simple, you’ll need to run the 32bit version of “odbcad32.exe” by running “c:\Windows\SysWOW64\odbcad32.exe” from Start/Run menu and create your ODBC DSN with this tool.

The key point here to remember is a 64bit machine should be considered as a “64 bit Windows + 32 bit Windows” at the sametime. That’s why the folder that our developers put the 32bit “odbcad32.exe” under C:\Windows\SysWOW64\ . The WOW abbreviation here means “Windows on Windows”  😉

That’s why, it might be a good idea to have a look at the C:\Windows\SysWOW64\ for the EXE files at least to know what sort of other EXEs/DLLs are also compiled as 32bit and shipped within your 64bit OS.

For example cscript.exe and wscript.exe are ther for your WSH (Windows Scripting Host) scripts which needs to be run as 32bit. Think about a scenario like that. Only the 32 bit version of the OLE DB Provider or ODBC Driver exists for the data source that you need to get the data from your VBScript code.  If it’s the case, you’ll need create the ODBC DSN (assuming that you’re going to use ADO + ODBC in your VBScript code) from C:\Windows\SysWOW64\odbcad32.exe and also you should call your script as

“C:\Windows\SysWOW64\wscript.exe C:\scripts\myscript.vbs”.

Doubleclicking the myscript.vbs from the Windows Explorer will result your script to be executed as

“C:\Windows\System32\wscript.exe C:\scripts\myscript.vbs”.

Hope I managed explaining the WOW philosophy for a 64 bit Windows a little bit in my words and can help you in your projects 🙂

Comments (13)

  1. jack Favor says:

    Thank you for the clarity of your explanation

  2. farukc says:

    thanks jack!

  3. Paul says:

    On a side note, any idea why user DSN are visible to 32bit apps but Stsyem ones are not?

  4. farukc says:

    User DSNs are available to the current user logged on to the machine. System DSNs are available to all users on the machine.

    if the User DSN is shown in 32bit odbcad32.exe and iIf the 32bit app is ran by the user's credentials all should work fine.

    Please check who runs the 32bit app by checking it from task manager to see which user is spawned it.

  5. Juraj says:

    Hi Faruk, thanks for explanation, but what if my odbcad32.exe from C:WindowsSysWOW64odbcad32 doesn't work, and it gives me just blank window with "i" in it. I'm having problem to get NotesSQL to ODBC as it's running from System32 folder only. Any idea?

  6. farukc says:

    Hi Juraj,

    C:WindowsSysWOW64odbcad32.exe should work and it's the first time that I hear it's showing a blank Windows with "i" in it.

    Could you please take a screenshot, upload to some image upload place and put a link here for me to see it ?

    thanks,

    faruk

  7. Joey G says:

    Thank you for the excellent explanation!

  8. justme says:

    Hi, I'm not a developer and I don't need ODBC.  So,  do I need C:WindowsSysWOW64wscript.exe ?

    My firewall blocks it.. so should I allow access to it?  Thanks…need your advise!

  9. Tobey Llop says:

    Wow! (pun intended) Finally a really good tidbit of info!  Thanks so much!

    Now I know why my cscript …vbs was giving me the architecture mismatch.

  10. SHN says:

    Thank you, this solved my problem with executing a vbscript through cscript, much appreciated!

  11. JonZ says:

    Thanks! My VBS was defaulting to the 32 bit wscript.exe engine. Specifying 64bit in the command line fixed the DB connection. Awesome!

  12. Aryan Nava says:

    yes, C:WindowsSysWOW64odbcad32.exe works