Oracle 10g and W2K8R2

At the office, a lot of people are using MS Excel. And they’re using the ability to fetch external data into Excel. This external data is read from an Oracle 10g database. Now, given the fact that we recently changed to a new Citrix environment, using Windows 2008 R2 (thus x64) servers, you can already guess: Reloading the data in Excel just won’t work.

After a little search on the Internet, I found a question about the exact same problem I have: the question for a “Solution for ORA-6413 error showing connection not open”

There’s just one answer.

Are you running a 32 bit Oracle client software on a 64 bit OS ?

It seems that this error is caused by a bug. The networking layer is unable to parse program locations that contain parenthesis in the path to the executable which is attempting to connect to Oracle, and 32 bit applications are installed in locations similar to “C:\Program Files (x86)\…” on 64 bit versions of Windows.

If that is the case, there are two solutions for this:

1) Use a version of the Oracle software that contains the fix for the bug (i.e. apply the latest available patch for the Oracle software)
2) Find the location of the application that is generating the error and relocate it to a directory without any parenthesis in the path.

Since it is a bug in the Oracle client, relocating the application to a folder without parenthesis is just a work-around. I’d go for solution 1: use a new version of the software. Luckily I still have that download from my previous Oracle troubles, on my x64 Windows 7 machine, and remembering the download took more than 30 minutes, I’m glad I can start installing immediately… Just to find out that the installer crashes as soon as it get launched.

Then I remembered.

Only a couple of days after finding a solution for my Oracle 10g troubles on Windows 7, a colleague of mine couldn’t start the installer either. What I couldn’t remember, is what the solution was. Luckily, there’s Google to show me that there’s a simple solution. Just moving the installer files to C:\ solves it and the installer works fine.

I said it before and I’ll repeat it. It IS still Windows after all…
Edit: As mentioned in the comments, it’s indeed not fair to blame the guys from Redmond. Totally agree.
And I forgot to mention that not only the installer just works after copying it to the root, the solution mentioned above did indeed work on the servers so Excel is now able to connect to the Oracle database.