Article ID: 328383
Article Last Modified on 12/30/2005
APPLIES TO
- Microsoft SQL Server 2000 Standard Edition
- Microsoft Data Access Components 2.6
- Microsoft Data Access Components 2.7
- Microsoft SQL Server 2005 Standard Edition
- Microsoft SQL Server 2005 Developer Edition
- Microsoft SQL Server 2005 Enterprise Edition
- Microsoft SQL Server 2005 Express Edition
- Microsoft SQL Server 2005 Workgroup Edition
This article was previously published under Q328383
SUMMARY
Client computers that have Microsoft Data Access Components (MDAC) version 2.6, or later, can try multiple protocols or Interprocess Communication (IPC) mechanisms to establish connections to SQL Server.
MORE INFORMATION
An enhancement has been made to the client side network library, Dbnetlib.dll for MDAC version 2.6, and later. With MDAC version 2.6, and later, if multiple protocols are available, and a connection attempt with the first protocol fails, the client application immediately tries to use one of the other protocols.
By default, clients have TCP and Named Pipes as available protocols. You can manipulate the protocol ordering by using the SQL Server Client utility. The client application uses the protocols in the order specified on the client computer. The protocol order is stored at the following registry key location under the value ProtocolOrder:
HKLM\Software\Microsoft\MSSQLServer\Client\SuperSocketNetLib
If you are using SQL Server 2005, the protocol order is stored in the ProtocolOrder registry entry under the following registry subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI9.0
For example, if a client computer has both TCP and Named Pipes available, and the order is:
- TCP
- Named Pipes
when the client computer tries to make a TCP connection to the server and the connection attempt returns a non-zero return code, the client transparently tries a connection by using the next protocol in the list, which is Named Pipes. In this scenario, the client cannot make a TCP connection; however, the client successfully makes a Named Pipes connection.
Note The client does not receive an error that indicates the first protocol failed.
If the client application uses the second protocol, and it also returns an error, an error is returned to the client.
If you make an alias by using one of the following methods, the client application uses the alias information to establish a connection to the server and does not use any additional protocols.
- By using the SQL Server Client Network utility
- By using SQL Server Configuration Manager (SQL Server 2005)
- When you create an ODBC data source name (DSN)
If you want to control the protocol that a client application uses for every connection attempt, and not allow the client to try multiple protocols, you can do one of the following:
- Use the SQL Client Network utility or SQL Server Configuration Manager to create an alias by specifying the protocol you prefer.
Specify the protocol in your connection string. For example:
"DSN=DSNName;SERVER=servername;DATABASE=YourDataBaseName;Network=DBMSSOCN;Address=IP_Address,1433;UID=YourUID;PWD=YourPassword;"
In this example, you specify the network protocol as "DBMSSOCN", which means that you want to use the TCP/IP protocol. If you specify the protocol inside your connection string, Dbnetlib only uses the specified protocol and does not try any other protocol. Similarly, to enable Named Pipe protocol only, use a connection string similar to this:
"DSN=DSNName;SERVER=servername;DATABASE=YourDataBaseName;Network=DBNMPNTW;Address=\\.\pipe\sql\query;UID=YourUID;PWD=YourPassword;"
- Use the Client Network utility to remove other protocols.
REFERENCES
SQL Server Books Online; topic: "SQL Server Client Network utility"
Keywords: kbinfo KB328383
