William
Thu Jan 06 14:40:20 CST 2005
The ODBC .NET data provider (unlike the OleDb provider) does not depend on
COM and (in my tests) is 20% faster. However, I do not (ever) suggest it's
use over "native" managed providers if one is available (like SqlClient or
the Oracle and other "real" managed providers that aren't simply wrappers
for their OLE DB providers.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
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.
__________________________________
"Patrice" <nobody@nowhere.com> wrote in message
news:OEZ3qoB9EHA.2452@TK2MSFTNGP14.phx.gbl...
> Even if it was so small, do you have a reason to prefer ODBC to the .NET
> provider ?
> I would see things the other way round, using the .NET provider unless I
> really need something in ODBC...
>
> Patrice
>
> --
>
> "Brett" <no@spam.net> a écrit dans le message de
> news:ur3%23ez58EHA.4028@TK2MSFTNGP15.phx.gbl...
>> Pablo,
>>
>> I understand all the extra work involved. I'm saying practically that it
>> doesn't really matter. With a good server, the time saved is the less
> than
>> the blink of an eye. No one is going to do any better off of 10ms.
>>
>> Brett
>>
>> "Pablo Castro [MS]" <pablocas@online.microsoft.com> wrote in message
>> news:OY5jWr48EHA.3868@TK2MSFTNGP15.phx.gbl...
>> > In general if you're working on a .NET application we recommend the
>> > .NET
>> > Data Provider for SQL Server because it has less layers, that is, the
>> > provider itself talks to the server (using TDS - in fact, the TDS
>> > parser
>> > itself is implemented in managed code). If you have a .NET app that
>> > uses
>> > the
>> > ODBC managed provider + the SQL Server ODBC driver, then you have .NET
>> > ODBC
>> > Driver --> ODBC Driver --> TDS, so you end up with an extra layer and
> all
>> > the marshalling and magic needed to have .NET use ODBC handles,
> bindings,
>> > etc.
>> >
>> > The ODBC managed provider is useful when talking to data-sources for
> which
>> > there is no managed provider but there is an ODBC driver available.
>> >
>> > I hope this helps clarify the issue.
>> >
>> > --
>> > Pablo Castro
>> > Program Manager - ADO.NET Team
>> > Microsoft Corp.
>> >
>> > This posting is provided "AS IS" with no warranties, and confers no
>> > rights.
>> >
>> >
>> > "Brett" <no@spam.net> wrote in message
>> > news:uD2XBWs8EHA.3988@TK2MSFTNGP10.phx.gbl...
>> >> Pablo,
>> >>
>> >> Thank you. If TDS are the actual data (packats), than how is there
>> >> any
>> >> speed difference between:
>> >>
>> >> 1. CFMX accessing SQL Server stored procedures via ODBC SQL Server
> driver
>> >>
>> >> 2. VB.NET accessing SQL Server stored procedures via .NET SQL Server
> data
>> >> provider
>> >>
>> >> In practical terms, how can this really be any faster? Option 2 may
>> > provide
>> >> 10 ms or so right?
>> >>
>> >> Thanks,
>> >> Brett
>> >>
>> >> "Pablo Castro [MS]" <pablocas@online.microsoft.com> wrote in message
>> >> news:ezaNy%23q8EHA.3820@TK2MSFTNGP11.phx.gbl...
>> >> > Let me clarify a little:
>> >> >
>> >> > TDS is an "application level protocol", that allows SQL Server
>> >> > server
>> > and
>> >> > clients communicate, ask for execution of SQL statements, specify
>> >> > parameters, describe result-sets metadata, send rows, etc.
>> >> >
>> >> > Client and server send and receive TDS packets through some
>> >> > "transport";
>> >> > typically the client and server TDS parsers don't even know what
>> > transport
>> >> > is being used, that's delegated to a lower layer. That lower layer
> uses
>> >> > some
>> >> > transport that's appropriate for each situation - it can be shared
>> > memory
>> >> > (if it's in the same box) or some network IPC such as sockets or
> named
>> >> > pipes.
>> >> >
>> >> > So if you're talking to SQL Server you're using TDS, regardless of
> the
>> >> > underlying transport mechanism.
>> >> >
>> >> > ** SQL Server 2005 will support non-TDS communications as well: you
> can
>> >> > use
>> >> > HTTP/SOAP to talk to the server. However, client providers still use
>> > TDS.
>> >> >
>> >> > --
>> >> > Pablo Castro
>> >> > Program Manager - ADO.NET Team
>> >> > Microsoft Corp.
>> >> >
>> >> > This posting is provided "AS IS" with no warranties, and confers no
>> >> > rights.
>> >> >
>> >> >
>> >> > "Brett" <no@spam.net> wrote in message
>> >> > news:OoRH1bg8EHA.3376@TK2MSFTNGP12.phx.gbl...
>> >> >> In order to use TDS via ADO.NET, does the SQL Server need to be on
> the
>> >> > same
>> >> >> machine?
>> >> >>
>> >> >> If not, this will have to involve TCP/IP or named pipes correct?
> How
>> >> >> does
>> >> >> TDS help in that case?
>> >> >>
>> >> >> Thanks,
>> >> >> Brett
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>