In order to test connectivity to SQL Server from UNIX, first ping the host to make sure the machine the SQL Server resides on can be talked to, as shown below:
$ ping <server_name>
Pinging server_name with 32 bytes of data
Reply from 10.16.17.17: bytes=32 time=1ms TTL=126
Reply from 10.16.17.17: bytes=32 time<10ms TTL=126
Reply from 10.16.17.17: bytes=32 time<10ms TTL=126
Reply from 10.16.17.17: bytes=32 time<10ms TTL=126
Ping statistics for 10.16.17.17:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
A successful ping shows that the network isn't preventing communication with the machine hosting the server.
The next step is to telnet to the port to verify that the SQL Server process is listening. On the UNIX prompt login, type the following command and hit the Enter key:
telnet <SQL_Server_Machine_Name> <Port_Number>
If the following message is displayed, it means that the SQL Server process is listening on that port:
To exit telnet, use Ctrl+] to escape to the command mode and then use 'quit.'
A 'Connection Refused' message, shown below, could mean a wrong host, port, or that the process is down:
In certain instances, no error message may be displayed and the telnet window may simply hang till a timeout may be reached. This is also a sign of inability to talk to the port, as shown below:
NOTE: If all the tests above are not successful, trying to establish connectivity using Strategy products will invariably fail. Hence, users need to work with database server administrators or network administrators or both and fix all such connectivity issues before contacting Strategy Technical Support. If testing connectivity with the server machine name does not work, but the IP address does, there may be a problem with DNS name resolution.
KB ID: 22634
