System.Data.OracleClient versus Oracle.DataAccess.Client (ODP.NET) RRS feed

  • Question

  • Oracle provides .NET classes for accessing an Oracle database.  These are derived from ADO.NET base classes and thus are highly compatible with everything else.  This library is sometimes referred to as ODP.NET and is found in the Oracle.DataAccess.Client namespace.

    Similarly, Microsoft provides .NET classes for accessing an Oracle database.  These are just the default classes provided with the .NET framework and are found in namespace System.Data.OracleClient.

    Both of these namespaces go through the Oracle client (OCI interface).  Thus, performance should be comparable.  I don't see how much difference there can be if you are using only the basic data types such as integers, numbers, and strings. 

    Oracle claims that ODP.NET is more stable and better performing than the Microsoft provided classes.  Is it true, or just a marketing gimmik? 

    Is ODP.NET there because it is needed, or is it there because Oracle wants to encourage developers to use Oracle-specific features (thus locking you in to Oracle)?

    Why would Microsoft provide "unstable" libraries?  Is this to encourage developers to use SQL server? 

    Bottom line, I need my code to run right.  I cannot accept defective libraries.  On the other hand, I do not want to waste time installing stuff that I do not need.



    Wednesday, March 15, 2006 12:02 AM


All replies

  • I found this link


    It appears the the ODP.NET Command Builder will avoid a round-trip to collect schema information.  I don't know how it does that.  Maybe it caches that information on the client. 

    The article does not talk much about performance beyond that. 


    Wednesday, March 15, 2006 1:38 AM
  • And here is another link


    If you search for the word "caching", you will see that ODP.NET does in fact cache some things.  Thus, it might be faster in some cases. 

    I do know that ODP.NET is also about 500 megs to download, and has various version dependencies with respect to the Oracle Client and the Oracle Server.  I am not looking forward to installing it. 



    Wednesday, March 15, 2006 1:44 AM
  • one of the big differences is that the microsoft client won't handle a blob/clob type greaten than 32k...
    I wish they would fix this problem.
    Monday, May 4, 2009 6:26 PM
  • No more fixing bugs. I read that Microsoft is going to discontinue the System.Data.OracleClient [Oracle Data Provider] from .NET4.


    Wednesday, June 17, 2009 6:23 PM
  • Tuesday, July 7, 2009 7:38 PM
  • Yes, Microsoft deprecated Oracle Client (http://blogs.msdn.com/adonet/archive/2009/06/15/system-data-oracleclient-update.aspx) and advised to use 3rd hand tools. We offer you to try Devart's tool dotConnect for Oracle: http://www.devart.com/dotconnect/oracle/

    It has FREE edition and the interface compatible to OracleClient with lots of usable features in addition. More detailed information about features and our support you could find on our blog article: http://www.devart.com/blogs/dotconnect/?p=67

             Enjoy dotConnect.

    Monday, September 21, 2009 12:02 PM
  • We recently purchased the Devart dotconnect software:

    Beware: The devart software uses .Net Component Licensing which is a huge pain. You must identify the end application name before compiling a class library.


    Thursday, March 25, 2010 3:21 PM
  • I'm developing in .NET 4.0 and recently had to re-write some of our older stuff that was using the System.Data.OracleClient.  We are running Windows 32 and 64 bit machines with throws in another level of complexity that ODP.NET doesn't work well with.

    After fighting with ODP.NET stuff for over a week, we've decided to work with the legacy/unsupported System.Data.OracleClient.  The ODP.NET stuff will work on a dev machine, but can't be deployed to the server.  One solution we came up with was to install Visual Studio on our Servers so we could compile our applications and services on the server. This worked for our in-house, but wasn't possible with client's servers.  Due to the lack of support from Oracle and the issues with ODP.NET, we are going to migrate away from Oracle all together and use SQL Server. 

    Wednesday, October 27, 2010 2:30 PM
  • I definitely agree with Golfnut - the ODP is sub-optimal. Oracle does not provide good support for Windows no matter what they say... Their installers are horrible Java things which don't work properly. You often can't deinstall things correctly using them. Their range of possible options for clients is confusing. Oracle has a nice database system, but they need to get their head out of their **s and think about the developer's user experience a bit!
    Friday, March 18, 2011 11:12 AM
  • I am going through this same pain for the past 2 or 3 days. In the past, we found certain things that worked better with the Microsoft driver and that was what recommended. Don't remember any more what it was. It has been about 6 years ago since I last used Oracle.

    But the Oracle Installs are still a mess.  When you want the 32 bit drivers that work on a 64 bit machine, you get the 64 bit drivers that don't make it clear that the 32 ones are in there too.

    Various installers failed, some ran okay, some said they need java.  Pretty much a mess.  I have something that seems to run now, but the compiler was whining about something with AMD64 and I don't know how that got into the equation.

    Thursday, October 22, 2015 6:16 PM