To view socket errors, use Vortex API logging or %SSC_GETEMSG. On UNIX systems, see /usr/include/errno.h. On Windows systems, you can find these errors in winsock.h or winsock2.h, which are typically distributed with Microsoft’s Platform Software Development Kit (SDK). For details on Microsoft error codes, see Microsoft documentation.

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:errorno: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.

If you can connect, then the network, the server, and the Synergy/DE OpenNet Server service (SynSQL) are working. Continue with step 2.

If you can’t connect, make sure that the server is running, that the SynSQL service is running on the server, and that vtxping or synxfpng is using the correct port.

Check and correct the following, which may solve the problem if it is caused by network timing issues:

If you’re using network licensing, make sure License Manager is configured as a network server.

Make sure the server was rebooted after the Connectivity Series components were installed.

Check the system‑level PATH on the server. It should include the connect directory.

Use vtxnetd or vtxnet2 logging and check the resulting tcm_pid.log file. Then check the event log on Windows, syslog on UNIX, or the operator console on OpenVMS. (For information on vtxnetd and vtxnet2 logging, see vtxnetd and vtxnet2 programs.)

Make sure the file(s) for the database driver you are using are in the connect directory on the server. On Windows, there are two files: an .exe and a .dll (e.g., vtx0_10.exe and vtx0_10.dll for Oracle). On UNIX, this is an .so file (e.g., vtx0.so). On OpenVMS, this is an .exe file (e.g., vtx0.exe).

Make sure there is no more than one vtxnet2 process running on the server. If there’s more than one, use vtxkill to kill the processes; then restart the service.

3.

If you’re on Windows or UNIX, run the dltest utility to make sure Connectivity Series DLLs or shared libraries are loading properly. (The dltest utility is a command line utility in the synergyde\connect directory and has no options.)

4.

Make sure the connect string in the client application is referencing a valid driver and database.

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.

For additional troubleshooting steps for prior versions of Connectivity Series, see the Synergex KnowledgeBase article 100001607.

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 SQL Connection program can’t make a connection to the SQL OpenNet server. The SQL OpenNet server may not be running, it may not use the port that’s specified in the connect string (or the default port if you didn’t specify a port in the connect string), or the host specified in the connect string 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.

If you can connect, then the network, the server, and the Synergy/DE OpenNet Server service (SynSQL) are working. Continue with step 2.

If you can’t connect, make sure that the server is running, that the SynSQL service is running on the server, and that vtxping or synxfpng is using the correct port.

2.

Make sure the port number specified in the connect string matches the port number used by the SQL OpenNet server, which is either the default port number or the port number used when starting vtxnetd or vtxnet2. For information on starting vtxnetd or vtxnet2, and for information on the default port number for a server, see Configuring Connectivity Series.

On UNIX, if you find that the SQL OpenNet server is running and the port is correct, it may be the case that the 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. For example: