Oracle Data Provider

[Dom]

Someone in a post mentioned the Oracle Data Provider. Can anyone tell
me about it? I'd like to know the following:

1. Is it much faster than OleDB?

2. Is it essentially the same approach, eg, new Connection, new
Command, set CommandText, ExecuteDataRead(), cursor through a
DataReader, and so on?

3. Is it something I just download from Oracle and then install? Is
there any downside? (Computer becomes slower, whatever).

Thanks,
Dom

 

[Mike]

Oracle Data Provider is a connection component that allows you to connect to
an Oracle database. You can CommandText, DataReader, DataSets, etc. I'm
using is now to connect to our Oracle warehouse and using all of the above
to execute my queries and return my data.

 

[Peter Bromberg [C# MVP]]

Any ADO.NET database-specific provider should be more efficient than OleDb.
If the provider is written correctly, it will have the same semantics. That's
why you have the interfaces for the providers - e.g. IDbCommand, IDataReader,
etc.
--Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com

 

[sherifffruitfly]

Someone in a post mentioned the Oracle Data Provider. Can anyone tell
me about it? I'd like to know the following:

1. Is it much faster than OleDB?

2. Is it essentially the same approach, eg, new Connection, new
Command, set CommandText, ExecuteDataRead(), cursor through a
DataReader, and so on?

3. Is it something I just download from Oracle and then install? Is
there any downside? (Computer becomes slower, whatever).

Thanks,
Dom

I've used Oracle's .net provider, and have been very happy with it.
It's definitely faster than going through oledb.

MS was nice enough to provide a comparison of the the MS offering and
Oracle's:

http://msdn2.microsoft.com/en-us/library/ms971518.aspx

It's dated, but it gives the idea.

Oracle's explanation of the speed improvement can be found somewhere
on their ODP.NET site. Bascially, the reason they give is that there
aren't layers-upon-layers to go through in making db accesses thru
ODP.NET

Downside to ODP.NET: deployment. Every client computer running
the .net-with-ODP.NET code must have odp.net installed - not just,
say, the computer with the db on it. This becomes annoying, and Oracle
has been hounded about this for some time. Possibly they've resolved
the deployment hassle - it's been awhile since I've used it.