INF: Open Failed on Network Pipe on Connect to SQL Server

  - Microsoft SQL Server version 4.2 for OS/2

SUMMARY

The following is a detailed description of diagnostics to do when attempts to connect to SQL Server from an MS-DOS client fail with the message:

   Open failed on network pipe.

MORE INFORMATION

If user-level security is active on the OS/2 server, be sure that NET LOGON with a valid username AND PASSWORD has been executed before attempting to connect to SQL Server. Be sure the username has been granted permission by the LANMAN administrator to use named pipes (sharename \PIPE).

If you can connect to SQL Server after issuing NET USE but not before, NET LOGON is not being executed correctly.

If NET USE prompts you for a password, you were logged on, but under an incorrect password. If NET USE prompts for both username and password, you were not logged on at all.

Check the NET ADMIN audit trail on the OS/2 server for attempted security violations. You can use the full-screen NET command to see what username you are currently logged in as. If the NET command forces you through a logon sequence, you were not logged on correctly.

You can use MAKEPIPE and READPIPE to get the error code. For details on how to use these diagnostic utilities, see the "Microsoft SQL Server Language Reference Manual" for version 4.2.

READPIPE error code 53 is the symptom of an incorrect NET LOGON. You need to be sure the MS-DOS workstation is completely logged on before attempting to use a named pipe.

If the username you used in the NET LOGON command does not exist on the server, or if that username does not have permission to use named pipes on the server, READPIPE will fail with error code 65. If, on the other hand, you do a NET LOGON specifying a username that does exist on the server and that has permission to use named pipes, you will get an error code 53 if that user has a password and you fail to include it in the NET LOGON command. This only happens the first time, and only with a missing password. Once a password is specified, it is saved.

If none of this seems to help, you can temporarily disable user-level security by changing the line "SECURITY=USER" to "SECURITY=SHARE" in LANMAN.INI.