Default Client Connection Behavior
After SQL Server Native Client is installed on a client computer, the client is immediately ready to connect to an instance of the Database Engine. In most cases, a SQL Server client does not need any special configuration to connect to an instance of the Database Engine. The only information that the client application must supply is the computer name and instance name. If the SQL Server Browser service is not running on the server, you must provide a connection endpoint (TCP/IP port or named pipe) to connect to a named instance.
The server network protocols are not enabled by default. For more information, see How to: Enable or Disable a Server Network Protocol (SQL Server Configuration Manager).
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:
"<computer_name>\<instance_name>" for a named instance
"(local)\<instance_name>" for a named instance
"localhost\<instance_name>" for a named instance
A single period "."
".\<instance_name>" 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:<computer_name>" or"tcp:<computer_name>").
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, "<computer_name>.<domain_name>.com"
Verifying Your Connection Protocol
The following query will return the protocol used for the current connection.
SELECT net_transport FROM sys.dm_exec_connections WHERE session_id = @@SPID;
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.
Compatibility with Earlier Versions of SQL Server
The default instance of SQL Server listens on the same network addresses as earlier versions of SQL Server, including Microsoft SQL Server 2000 and Microsoft SQL Server 7.0. Applications using earlier versions of the client connectivity components can continue to connect to the default instance with no change. Named instances of SQL Server listen on dynamic ports. Client computers using earlier versions of the client connectivity components must be set up to connect to these addresses. For more information, see How to: Create a Server Alias for Use by a Client (SQL Server Configuration Manager).
If SQL Server Native Client or a Microsoft Data Access Components (MDAC) client is already installed, the protocol settings are preserved. For new installations, all protocols except VIA are enabled on the client, and are attempted in the following protocol order: shared memory, TCP, named pipes.
The VIA protocol is deprecated. This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
To connect to a named instance, MDAC clients must upgrade to at least MDAC 2.6.
To enhance security, SQL Server disables TCP/IP connectivity to SQL Server for new installations of the Developer, Evaluation, and SQL Server Express editions. OLEDB applications connecting with MDAC 2.8 cannot connect to the default instance on local server using ".", "(local)", or (<blank>) as the server name. To resolve this, supply the server name, or enable TCP/IP on the server. Connections to local named instances are not affected, and connections using SQL Server Native Client are not affected. Installations where a previous installation of SQL Server is present might not be affected.