Open topic with navigation
TCP/IP socket errors have the following mnemonics:
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.
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.|
|2.||Check and correct the following, which may solve the problem if it is caused by network timing issues:|
|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.
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.
|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:
nohup vtxnetd &
For more information, see Starting SQL OpenNet for SQL Connection.