Home > .net 3.5, Microsoft, Oracle, Visual Studio 2008, Windows Server, Windows Vista, Windows XP > Oracle Data Access Components (ODAC) with 64-bit Development

Oracle Data Access Components (ODAC) with 64-bit Development

November 21, 2007

Oracle has always been kinda touchy to install.  For Windows users, the simple fact that it forced its way onto the root was an annoyance at worst.  With the 10g and higher client tools, it’s even worse—Oracle doesn’t want to control just itself, but the location of ALL applications that call it.

 

If the file path of a calling application contains characters such as parenthesis, the application will fail.  This behavior is by design and currently, according to Metalink, does not have a fix.  Why is this setup this way?  No one knows.

 

This really isn’t a rub until you install Oracle onto a 64-bit Windows machine.  64-bit Windows installs two Program Files directories, one for x64 native applications and one for x86 native/WoW applications.  Unfortunately, the x86 directory is called… “Program Files (x86)”.

 

Now, for Oracle, this isn’t a big deal.  It’s happy in its “c:\oracle” directory.  I’m sure other Oracle apps install in a similar pathing structure to avoid the Program Files directory.  So, you probably won’t see this issue on a production server.  However, what about 64-bit development workstations?  All of our programs are in the (x86)-esque directory.  What does that mean?  They fail.  Even if using the 64-bit Oracle Development tools and clients… they still fail.

 

When it fails, you receive an error message that tells you exactly what’s wrong.

 

“ORA-06413: Connection not open.”

 

Ehh.  Yeah, that’s very helpful.

 

The fix?

 

According to Oracle?  There’s nothing you can do right now, a full 64-bit implementation hasn’t been created.  They acknowledge the issue, but don’t seem to care.  The hot fixes made available a few months ago (metalink #5059238 and #4751549) only addresses 32-bit issues (and, according to forum posts, not entirely).  In addition, there are workarounds to emulate a 32-bit environment, but…  that doesn’t get you past the parenthesis issue.

 

According to the community?  Uninstall your applications and reinstall them into a different path.  For example, with Visual Studio, you need to take it out of “C:\Program Files (x86)\Visual Studio 9.0\” and place it in another directory sans-parenthesis, like “C:\DevTools\Visual Studio 9.0\”. 

 

According to trial and error?  Give up on the platform-based 8i, 9i, and 10g tools.  The 11g BETA Oracle Data Access Components (11.1.0.6.10) works.  There isn’t a 32 or 64-bit code set for this download; however, looking it the GAC, the 2.111.6.10 version of Oracle.DataAccess is registered as an x86 (32-bit) library.  If you need Client access, the 11.1.0.6.0 11g Release 1 Client for x64 also works.

About these ads
  1. Jon
    November 4, 2008 at 2:56 pm

    I am so frustrated with ORACLE and the x64 environment. I have tried so many things in order to get a connection but nothing works. I am going to try your suggestions now and see what happens. I keep getting the 3706: Provider not found or not installed message. Hopefully the BETA install works ok. Thanks

  2. November 4, 2008 at 3:42 pm

    @Jon-

    Good luck.. I’m drafting a post now of rolling out from a x64 box and actually publishing x64 web sites with Oracle. Versions are KILLING me. :(

  3. March 12, 2009 at 1:27 pm

    “According to the community? Uninstall your applications and reinstall them into a different path. For example, with Visual Studio, you need to take it out of “C:\Program Files (x86)\Visual Studio 9.0\” and place it in another directory sans-parenthesis, like “C:\DevTools\Visual Studio 9.0\”. ”

    This problem had been bothering me for more than two years now. Since I got the 64bit computer. I got almost everything working under the x86 mode including ASP.NET, Winform, Oracle client, except only the nunit with TestDriven.NET debugging mode in Visual Studio.

    Today, I took a 2nd look at this advise. Suddenly, a “light bulb” turned on. Why I didn’t try “C:\DevTools\TestDriven”? After reinstalling it. And then, the miracle happened, when I step through the code in IDE with TestDrive, the Oracle connection .open passed successfully, the first in more than 2 years!

    All I can say is: Thank you! Thank you! Thank you!

    Cheers!

  1. No trackbacks yet.
Comments are closed.
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: