Re: Is TDS used only if server is local?

From: Patrice (nobody_at_nowhere.com)
Date: 01/06/05 

Date: Thu, 6 Jan 2005 19:04:32 +0100

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
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Relevant Pages

  • Re: Kein ODBC Support im SQL Server 2005 x64?
    ... Es gibt *keinen* ODBC Support im SQL Server 2005 x64 Standard mehr. ... Den Provider MSDASQL gibt es nicht mehr unter SQL2005 x64!! ...
    (microsoft.public.de.sqlserver)
  • Re: Is TDS used only if server is local?
    ... The ODBC .NET data provider does not depend on ... CFMX accessing SQL Server stored procedures via ODBC SQL Server ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Is TDS used only if server is local?
    ... TDS is what SQL Server understands!! ... Both SQLServer provider and OleDB provider use TDS eventually, ... > you better performance than the OLE DB Data Provider." ...
    (microsoft.public.dotnet.framework.adonet)
  • Linked server to ODBC DSN
    ... Server, and want to create a linked server to this same ODBC DSN: ... Provider = "Microsoft OLE DB Provider for ODBC Driver" ... Then i connect to the SQL Server using QA, and try to run my query (that ...
    (microsoft.public.sqlserver.server)
  • Re: Is TDS used only if server is local?
    ... Data Provider for SQL Server because it has less layers, that is, the ... provider itself talks to the server (using TDS - in fact, ... ODBC managed provider + the SQL Server ODBC driver, ...
    (microsoft.public.dotnet.framework.adonet)