Behavior of SQL Server 2000 network library during dynamic port detection
This article was previously published under Q286303
This article has been archived. It is offered "as is" and will no longer be updated.
This article discusses the behavior of the SQL Server 2000 network libraries as related to dynamic port detection.
The SQL Server 2000 Books Online documentation describes many of the enhancements to the network libraries. Specifically, the ability to dynamically determine ports for secondary instances.
SQL Server 2000 clients use DBNETLIB to perform to detect the ports. DBNETLIB is always loaded by the ODBC or SQLOLEDB components. DBNETLIB is responsible for making either direct IP/SPX calls or forwarding requests directly to the Shared Memory, Named Pipes or other network libraries. DBNETLIB also handles the protocol preference order when secondary protocol attempts are necessary.
The Client Configuration Utility has been extended to provide an option for dynamic port detection. When you enable the Client Configuration Utility, no port number is stored for the alias entry and DBNETLIB attempts to contact the server through a known UDP port to obtain the correct connection information.
Note Dynamic port detection is only aavailable for named instances of SQL Server 2000. The behavior of SQL Server 2000 for a default instance is exactly the same as in earlier versions of SQL Server. The network libraries assume either 1433 or the global default port established with the Client Configuration Utility.
If a default instance is listening on a port other than the standard 1433 port, you can provide an alias or change the global default port. You can also connect to the instance of SQL Server by using its server name, its FQDN, or its IP address followed by a comma and the port number.
fail Recv Connect WrapperRead
Article ID: 286303 - Last Review: 12/06/2015 00:05:56 - Revision: 4.2
Microsoft SQL Server 2000 Standard Edition
- kbnosurvey kbarchive kbhowto kbinfo KB286303