I do not have any timings to add, but I want to say that I had heard the 
same thing, that using OLEDB* goes thru the Interop layer.  That, in 
addition to NOT being optimized for TDS would explain the performance hit 
for using OLEDB* providers (and also why ORacle is working so hard to 
create their own "native" provider for .NET).

R

> It is my understanding that he SQL* objects are .NET framework objects 
and
that he OLEDB* objects are wrapped COM objects.  You certainly can 
reference
SQL server with the OLEDB* objects, but you are probably better off not
doing so.  I have not seen any timed comparisons of the two, has anyone
seen?

----- Original Message -----
From: "Tahira" <tahira_aslam@y...>
To: "pro_VB_dotnet" <pro_vb_dotnet@p...>
Sent: Wednesday, May 29, 2002 2:45 AM
Subject: [pro_vb_dotnet] DOTNET Data provider


> I have a little confusion about ADO.NET data providers.Its documentation
> says
> "The SQL Server .NET Data Provider uses its own protocol to communicate
> with SQL Server. It is lightweight and performs well because it is
> optimized to access a SQL Server directly without adding an OLE DB or 
Open
> Database Connectivity (ODBC) layer. The following illustration contrasts
> the SQL Server .NET Data Provider with the OLE DB .NET Data Provider. 
The
> OLE DB .NET Data Provider communicates to an OLE DB data source through
> both the OLE DB Service component, which provides connection pooling and
> transaction services, and the OLE DB Provider for the data source."
>
>
> It means that OLEDB layer makes difference between SQLServer data 
provider
> and OLE DB data provider.Then why when we use SQLconnection,its "Data 
Link
> properties" shows "Microsoft OLEDB provider for SQL Server" on provider
> tab ?..Does it mean SQLconnection is using OLE DB layer?
> ---
> Change your mail options at http://p2p.wrox.com/manager.asp or
> to unsubscribe send a blank email to