Performance comparisons (OleDbDataAdapter v/s SqlDataAdapter)

Performance comparisons (OleDbDataAdapter v/s SqlDataAdapter)

Post by BBT » Wed, 12 Sep 2001 10:33:53



Is there any hard data showing the advantage of using SqlDataAdapter
on SQL Server 2k over using OleDbDataAdapter on SQLServer 2k?
I would really appreciate if someone could point me to a link/document.

Thanks,
Bharat

 
 
 

Performance comparisons (OleDbDataAdapter v/s SqlDataAdapter)

Post by Jay B. Harlo » Thu, 13 Sep 2001 05:59:01


Bharat,
According to Professional C#, from Wrox, the SqlDataAdapter is about twice
as fast as the OleDBDataAdapter.

However, MS does not allow publishing benchmarks of .Net as it is still in
beta!

Hope this helps
Jay


Quote:> Is there any hard data showing the advantage of using SqlDataAdapter
> on SQL Server 2k over using OleDbDataAdapter on SQLServer 2k?
> I would really appreciate if someone could point me to a link/document.

> Thanks,
> Bharat


 
 
 

Performance comparisons (OleDbDataAdapter v/s SqlDataAdapter)

Post by Michael Giagnocav » Fri, 14 Sep 2001 01:28:37


MSDN has some benchmarks, or was it GotDotNet?  Somewhere, I saw a table
showing DataReader vs DataSet with SQL and OLEDB.

Dataset SQL is around 2 times faster.  DataReader SQL is almost 4 times
faster, if I remember correctly.
-mike



> Bharat,
> According to Professional C#, from Wrox, the SqlDataAdapter is about twice
> as fast as the OleDBDataAdapter.

> However, MS does not allow publishing benchmarks of .Net as it is still in
> beta!

> Hope this helps
> Jay



> > Is there any hard data showing the advantage of using SqlDataAdapter
> > on SQL Server 2k over using OleDbDataAdapter on SQLServer 2k?
> > I would really appreciate if someone could point me to a link/document.

> > Thanks,
> > Bharat

 
 
 

1. Performance comparison of SQLOLEDB versus native SQL Server data provider

I'm writing a database helper component for a web application for use within
our company. This component will interface with a SQL Server 7.0 database
for now, but that might change to another database - possibly Oracle - in
the future (unlikely, but possible). Right now I have two options:

1. Write the helper class for use with the native SQL Server data provider,
and make sure the class consumers never have to use any SqlClient-specific
types. This means I will have to provide a custom type (struct) for passing
parameters, and convert these parameters to SqlParameter within the helper
class (BTW, if anybody of you has another suggestion to solve this problem
I'd appreciate it). If we switch to another database in the future, I would
have to change the types used by this class (SqlCommand to OleDbCommand,
etc.), but the code of the class consumers wouldn't need any changes.

2. Write the helper class for use with OleDb (i.e. use the SQLOLEDB
provider). If we choose this option, I wouldn't have to create any custom
types, and the application would continue to work if we would switch to
another database.

Obviously, option 2 is easier, requires less work and is less error-prone.
Option 1 is faster, however (as long as we keep using SQL Server, which is
very likely). So the big question here is:

"How big is the performance difference between using the native SQL Server
provider and using the SQLOLEDB provider ?"

Are there any bechmarks, test results, analyses, etc... online ? I would
really like to know how much performance is sacrificed if we decide to
choose option 2.

Thank you in advance.

2. Speech Quality Measurement (ITU-T P.861)

3. Performance Comparison: Data Access Techniques

4. HP 3200C and halftones

5. .NET Performance comparison

6. FS: Illustrator for Mac (new/unopened)

7. Performance Comparison of ADO vs ADO.NET vs ODBC

8. sql query for a date field

9. Comparison of Performance Issues with C#

10. Performance comparison between objects and include files

11. Database Update Performance question/comparison

12. Performance: SqlParameters vs straight command string, DataSets vs SqlDataAdapters

13. Need for Performance Engineer (not QA but Performance).Chandler, AZ