Troubleshooting socket errors

Connection reset by peer (10054 or 54) and Connection refused (10061 or 61) are the two most common socket errors.

Connection reset by peer (10054 or 54)

The “Connection reset by peer” socket error, which is 10054 (WSAECONNRESET) on Windows and generally 54 (ECONNRESET) on Unix and OpenVMS, indicates that a connection to the server has been closed. This could be caused by a fatal error on the server, the server stopping, a network problem, or even a connection problem.

1. If the error has the form “connect:errno:error”, use vtxping (or synxfpng with the -x option) to test your ability to connect to the server. Otherwise, skip to step 2. The vtxping and synxfpng utilities print reports to the screen. This information can be used by your network administrator to resolve TCP/IP network socket communication problems.

For more information see vtxping utility and synxfpng utility.

2. Check and correct the following, which may solve the problem if it is caused by network timing issues.
3. If you are on Windows or Unix, run the dltest utility to make sure Connectivity Series DLLs or shared libraries are loading properly.
4. Make sure the dictsource and datasource lines in the connect file on the server have the correct settings. Then check the settings in the DSN. For example, if the DSN specifies a port, it should be the port that the SQL OpenNet server is running on. (If the SQL OpenNet server is running on the port that’s the default for the client, the DSN doesn’t need to specify a port. See Configuring Connectivity Series for more information.)
5. If you get this socket error again, use vtxnetd or vtxnet2 logging and check the event log on Windows, syslog on Unix, or the operator console on OpenVMS.

Connection refused (10061 or 61)

The “Connection refused” socket error, which is 10061 (WSAECONNREFUSED) on Windows and is generally 61 (ECONNREFUSED) on Unix and OpenVMS, indicates that the xfODBC driver can’t make a connection to the SQL OpenNet server. The SQL OpenNet server may not be running, it may not use the port specified on the client side for the connection (see Port settings), or the host specified in the DSN may be incorrect.

1. Use vtxping (or synxfpng with the -x option) to test your ability to connect to the server. (For more information see vtxping utility and synxfpng utility.)

The vtxping and synxfpng utilities print reports to the screen. This information can be used by your network administrator to resolve TCP/IP network socket communication problems.

2. Make sure the host name in the DSN is correct.
Note

On Unix, if you find that the SQL OpenNet server is running and the port is correct, it may be that server is terminating when the user that started it logs out. To run the server in the background and keep it running after you log out, use the nohup command:

nohup vtxnetd -1958 &

For more information, see Starting SQL OpenNet for SQL Connection.