Why can I connect to SQL Server with the tcp-ip sockets netlib and not named-pipes over IP/multiprotocol?

A. Both these net-libs do indeed run over tcp-ip, so there are three reasons why ip sockets may work and named-pipes doesn't :-

1. Trusted connection. Tcp-ip sockets net-lib with SQL 6.5 and below does not require NT authentication whereas the other two do. For trusted connections you must be connecting from an NT domain/userid that the SQL Server machine can authenticate via it's domain controller - usually this means a trust is needed if different NT domains are used for client and server.

To prove whether this works or not you can do a NET VIEW \\servername from the client. If this returns "invalid logon", "no domain controller exists" or "access denied" then the appropriate trust/credentials are not in place.

2. Name resolution. You have probably done a PING <servername> and it has returned ok. This is fine for tcp-ip sockets as the name resolution methods are the same for PING as for sockets. However, for named-pipes a different set of name-resolution methods is used (see NT Resource Kit/Technet for full details). Try a NET VIEW \\servername from the client to see if this connects ok - if it gets "error 53" then name resolution is probably the problem.

3. Firewall sockets. Each of the net-libs use different tcp-ip port numbers, so if there is a firewall involved maybe the correct ports are not being opened :-

For tcp-ip sockets the default port for SQL Server is 1433.

For multi-protocol (rpc) the ports are normally variable, but you can fix them. See Q164667 in the Microsoft knowledgebase for details.

For named-pipes over ip 137/138/139 are used. As these are the same ones used for file/print it is not recommended you allow these through the firewall.

End of Article