Testing that SQL Server 2005 is listening for FreeTDS

Solution 1:

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 111.222.111.222 ... (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.

Solution 2:

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:

http://support.microsoft.com/kb/265808