views:

560

answers:

1

Hello everyone,

I am using VSTS 2008 + C# + ADO.Net + SQL Server 2008. My questions about what kinds of communication protocols SQL Server 2008 will be using, more details of my questions,

  1. If the connection string looks like this, whether Named Pipe or TCP/IP is used? Will different communication protocol being used dependent on whether client and SQL Server on the same machine?

    Data Source=labtest1;Initial Catalog=CustomerDB;Trusted_Connection=true;Asynchronous

  2. In SQL Server Configuration Manager, there are items called "SQL Server Network Configuration" and "SQL Native Client 10.0 Configuration". I find both of them has configuration options (for communication protocols) of Named Pipe or TCP/IP, what are the differences between "SQL Server Network Configuration" and "SQL Native Client 10.0 Configuration"?

thanks in advance, George

+2  A: 

According to SQL Server 2008 Books Online, this is what happens:

Connecting Locally on the Server

When you connect to the Database Engine from a local client (the client application and SQL Server are on the same computer), the connection uses shared memory protocol by default. SQL Server Native Client accepts any of the following formats to connect locally using the shared memory protocol:

  • ""
  • "\" for a named instance "(local)"
  • "(local)\" for a named instance
  • "Localhost"
  • "localhost\" for a named instance
  • A single period "."
  • ".\" for a named instance

To connect locally using another protocol (for troubleshooting), do one of the following with the protocol enabled:

  • Connect to a client alias that specifies a protocol. For more information, see "Aliases" in SQL Server Configuration Manager help.
  • Prefix the computer name with the protocol (for example, "np:" or "tcp:").
  • Connect to the IP address which results in a TCP/IP connection.
  • Connect to the fully qualified domain name (FQDN) which results in a TCP/IP connection (for example, "..com"

Connecting over the Network

By default, the default protocol for SQL Server clients is TCP/IP. If the connection cannot be made using TCP/IP, the other enabled protocols are attempted. A shared memory connection cannot be made over a network. Use SQL Server Configuration Manager to enable or disable client protocols, and to change the order in which connection attempts are made.

In the Sql Server Configuration Manager, you can define an order for the client protocols - I would assume that's the order the client tries to connect to SQL Server with. Whichever protocol is the first being supported by the server will be used.

AS for the configuration utility:

  • SQL Server Network Configuration is all about configuration of network protocols on the server side of things
  • SQL Native Client Configuration is the client-side configuration

If you have a dev box with both on it, you'll see both. A regular PC connecting to a SQL Server typically doesn't have SQL Server itself installed on it locally, so the server-side settings are meaningless there, obviously.

Marc

marc_s
Marc, 1. I want to confirm with you that when using 127.0.0.1, TCP/IP will be used? 2. "SQL Native Client Configuration is the client-side configuration" -- I am confused. Client cannot choose the protocol by using connecting string? My confusion is, suppose we configure client protocol on server machine, but client is on another computer, I think it should be the client who is responsible to configure which protocol the client is using, (I can understand server could manage server side protocol) but how could the server manage protocol preference for a remote client?
George2
"If you have a dev box with both on it," -- both you mean what?
George2
@George2: yes, the doc says "Connect to the IP address which results in a TCP/IP connection." --> connecting to 127.0.0.1 will use the TCP/IP protocol (if enabled on the server)
marc_s
On the client, you can configure which of the four protocols are supported. Only those that are supported can be used; those that are supported can be chosen by connection string.
marc_s
And it's **NOT** the server that configures the client - it's the admin that installs the SQL Native Client on the client machine that will configure that.
marc_s
If you have a dev box with both the SQL Native Client (client-side) and the SQL Server itself (server-side) on one and the same machine.
marc_s
You mean if I "have a dev box with both the SQL Native Client (client-side) and the SQL Server itself (server-side) on one and the same machine", then the SQL Server Native Client settings from SQL Server configuration manager impacts the native client on the same machine (which SQL Server exists)?
George2
Another confusion is what exactly means native client? If I am developing a managed console application using ADO.Net to connect to SQL Server, is the managed console application native client? If not, what means native client?
George2
No no no - the settings for client and server are **ALWAYS** separate - even on a dev box. On a dev box, you'd just have to set **BOTH** the server **AND** the client settings, since that machine is at the same time a SQL Server and a SQL Client.
marc_s
And yes, you might be developing only managed console apps - but not everyone does. There's still lots of folks out there who use Delphi, VB6 or other native languages. That's why the SQL Client is "native", e.g. supports both direct Win32 apps as well as managed apps.
marc_s
Thanks Marc! Question answered!
George2