BUG: Slow TCP/IP Connection to SQL Server from NT & DOS Client

• Microsoft SQL Server, version 4.21a

SYMPTOMS

The initial TCP/IP sockets connection to SQL Server from Microsoft Windows NT and MS-DOS clients using DBMSSOCN.DLL and DBMSSOC.EXE, respectively, can be very slow due to the abnormal IP address resolution behavior in these client-side Network Libraries (Net-Library).

The TCP/IP client-side sockets Net-Libraries for Windows NT and MS-DOS (DBMSSOCN.DLL and DBMSSOC.EXE) try to resolve host address even if the SQL Server's IP address is already hardcoded in the connection string.

This unnecessary attempt to resolve IP address can cause substantial delay in the initial connection. This is because the Net-Library tries to use the IP address as the host name to resolve the host address, which will eventually fail as expected. However, the failed attempts can cause substantial delay as the client has to wait for either the broadcast or point-to-point connection timeouts, depending on how the client is configured for IP host resolution.

CAUSE

The Net-Library calls GetHostByName() to resolve IP address whether a host name is used or not. Therefore, if an IP address is used instead of a host name, this call will cause the workstation to broadcast unnecessarily if b- node is used, which in turn causes the connection delay.

WORKAROUND

You can workaround this problem by using a host name rather than the IP address in the connection string. When you use the host name, the client will try to resolve its address using the appropriate host address resolution mechanism configured on the client. Because the host name should be resolved successfully, the time it takes is much shorter than the failed address resolution attempts if you hardcode the IP address. Based on this, there are two workarounds:

• Configure the client to use WINS: If WINS server is available on your network, it is recommended that WINS is used for IP address resolution due to its efficiency as a point-to-point node (p-node).

• If WINS is not used on the client, typically the client is defaulted to Microsoft Modified b-node, which means the client will check the LMHOSTS cache first, and then broadcast, and finally look it up in LMHOSTS. If broadcast can not resolve the address (because the server is on the other side of a router, for example), you can add the host name and address in the LMHOSTS file for lookup. Using this method, the first connection will still be a little slow due to the failed broadcast, but any subsequent connection attempts should be fast because the address is available in cache.

STATUS

Microsoft has confirmed this to be a problem in Microsoft SQL Server version 4.21a. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.