Consider that anytime a .NET application has to execute COM code (as it
needs to when it uses OLE DB), it has to do so via a COM Interop which takes
time and hurts performance. The SqlClient and Oracle .NET data providers use
"native" managed code. For the first time since DBLib, these providers can
use their native "language" to communicate with their targeted data source.
This means the SqlClient uses TDS to communicate to Microsoft SQL Server and
JUST SQL Server. The provider does not have to include any code to support
any other data provider. The OLE DB provider has tons of code to support the
generic interface that has to communicate with a data source-specific
provider--a two-step process.
SqlClient also supports a number of features that aren't supported on OLE DB
or even all other .NET data providers. For example the SqlClient provider
knows how to manage and monitor the connection pool.
Okay, the differences won't be that great. But I expect we'll see more and
more performance from native .NET providers and more and more data
source-specific functionality to make them even more powerful.
hth
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
