Oracle ODP.NET version agnostic alternative

Question

I am implementing an x64 application, connecting to Oracle.

What driver should I use, to make sure that it doesn't matter what client version the user has installed.

So, right now I'm building my versions with an x64 and x86 ODP.NET driver, but I'm worried that this won't work when the user has an older/newer version of the Oracle client (ODP.NET) installed.

Should I move over to OleDB or System.DataAccess drivers, to avoid this problem, or won't there be a problem at all?

PS: I was previously using the ODBC driver, but there are known bugs on x64 for this, so this is not an option.

Answer 1

Oh the 'joys' of Oracle... Ok basically, I never bothered with x64 versions, I just compiled my programs for 32 bits exclusively, so if that's a hard requirement not everything may apply for you.

But how I got version agnostic was to simply not use any client-installed drivers; instead I deployed in my application directory both the libraries for Oracle Instant Client, and the ODP binaries; the ODP will use OCI (instant client) files if they are accessible. It was the easiest way out and I'm glad I solved it that easily, although the information for this wasn't exactly easily reachable.

With the current versions (at least they were current when I last built the application), 11g, the combination of ODP and OCI ensured compatibility with versions 9-11.

Now, granted, OCI is pretty big (the english-only version is smaller at 'only' 35-ish MB if memory serves), but I had to live with it (deployment wasn't a big problem for me). Besides I had another dependency on a library which was already 50-ish MB - most of it in XML serialization assemblies! Don't get me started...

Hope this helps!

Answer 2

I'm afraid this won't work. Whatever driver you use, the directly or indirectly use the native OCI.DLL within the same process. And in your case, it must be the 64 bit version. So your application won't work with the 32 bit OCI.DLL.

To work around this, you have two options:

1. Write a separate 32 bit application responsible for accessing Oracle and somehow communicate with that application.

2. Embed a 64 bit version of the Java VM and access Oracle via OJDBC (the only option independent of OCI.DLL).

But I guess, these aren't very realistic options.