What is the best way to test that SQL Server 2005 is listening on an IP and port?

Some Background: I'm trying to connect a Unix box to SQL Server 2005 using freetds. However tsql keeps telling me that "Adaptive Server is unavailable or does not exist." I'm trying to figure out if the problem lies with my configuration of SQL Server or of FreeTDS. (The SQL server is currently being utilized as a datasource for a server running some .net websites; so I'm leaning towards the problem being on the UNIX side)


You could try to telnet your server at port 1433. It is the port SQL Server is listening to:

 telnet MySQLServerAddress 1433

The output should be

 Trying ... (example)
 Connected to MySQLServerAddress.

If you receive a 'Connection refused' error message, you're there is something wrong with the network communication (firewall on server, SQL Server port was changed from default, ...)

To exit telnet when connected, type the escape character Ctrl-]. Once in command mode, telnet may be exited with the command 'quit.'

If the basic network communications is working, you could test accessing the database server using "tssql":

It can be run in two ways, one which uses freetds.conf and one which connects directly using address/hostname and port bypassing freetds.conf. Try to connection using host and port first:

$ cd src/apps
$ TDSVER=7.0 ./tsql -H SQLServerHost -p 1433 -U user

If you receive 'Login Failed,' then you have a authentication issue.

If you receive a message like

Msg. No.: 18450 Severity: 14 State: 1 Login failed- User: loginid Reason: Not defined as a valid user of a trusted SQL Server connection

SQL Server is accepting only "domain" logins. This applies only to Microsoft SQL Server and you'll need to have your DBA verify that "server logins" are allowed, or use a domain login.

if you receive a prompt, then try tsql using the dataserver name (using freetds.conf):

$ ./tsql -S SQLServerHost -U user

If this fails, FreeTDS is either not finding the right freetds.conf file, or there is an error in the file.


I ran across a very similar problem. It took me hours to figure out what was wrong, but in the end it turned out that I was trying to connect to a named instance and the standard 1433 port was the wrong one to use:

Are you connecting to a named instance of sql server? If so see here:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy