FreeTDS Development Group

["Andrew Mattie" <amattie AT chilitech.net>]

I'm trying to use FreeTDS to access my MS SQL database. I can successfully
connect to it using tsql, as shown below.

testuser@localhost:~/freetds-0.63/src/apps$ ./tsql -H myserver.mydomain.com
-p 1433 -U EmployeeRadius
locale is "en_US"
locale charset is "ISO-8859-1"
Password:
1> 

The problem occurs when I try to do anything with the DSN I have created in
my /etc/odbc.ini file or even when I try to run the unit tests using 'make
check.' My /etc/freetds/freetds.conf file, which has global read permissions
on it and a symbolic link called /etc/freetds.conf which points to it, looks
like this:

[MyServer]
        host = myserver.mydomain.com
        port = 1433
        tds version = 8.0

When I run the unit tests, they all pass until they come to the ODBC tests,
in which case 29 / 30 of them fail. The failure message for the last test is
below; the others are very similar.

connection parameters:
server:   'MyServer'
user:     'EmployeeRadius'
password: '????'
database: 'pubs'
Unable to open data source (ret=-1)
SQL error S1000 -- [FreeTDS][SQL Server]Unable to connect to data source
FAIL: typeinfo
PASS: const_params

In trying to diagnose the problem, I copied my freetds.conf file to
~/.freetds.conf. I ran the unit tests again after the file had been copied,
and only 1 out of 30 of the ODBC unit tests failed. In following a recent
thread on the subject,
https://lists.ibiblio.org/sympa/arc/freetds/2005q3/018778.html, I exported
the TDSDUMP and TDSDUMPCONFIG environment variables so I could see some
better logs. The log file for the unit test where only 1 of the 30 tests
fail is below:

16:56:42.422755 Starting log file for FreeTDS 0.63
        on 2005-08-12 16:56:42 with debug level 99.
16:56:42.422933 iconv to convert client-side data to the "ISO-8859-1"
character set
16:56:42.423095 tds_iconv_info_init: converting "ISO-8859-1"->"UCS-2LE"
16:56:42.423208 tds_iconv_info_init: converting "ISO-8859-1"->"UCS-2LE"
16:56:42.423284 Connecting to xxx.xxx.xxx.xxx port 1433, TDS 7.0.
...

When I removed the .freetds.conf file from my home directory, the log file
is much shorter (12 lines) and looks like this:

17:00:58.549783 Starting log file for FreeTDS 0.63
        on 2005-08-12 17:00:58 with debug level 99.
17:00:58.567793 names for ISO-8859-1: ISO-8859-1
17:00:58.567894 names for UTF-8: UTF-8
17:00:58.567948 names for UCS-2LE: UCS-2LE
17:00:58.567999 names for UCS-2BE: UCS-2BE
17:00:58.568057 iconv to convert client-side data to the "ISO-8859-1"
character set
17:00:58.570237 tds_iconv_info_init: converting "ISO-8859-1"->"UCS-2LE"
17:00:58.570401 tds_iconv_info_init: converting "ISO-8859-1"->"UCS-2LE"
17:00:58.570475 IP address pointer is NULL
17:00:58.570535 Server MyServer not found!
17:00:58.570588 tds_free_all_results()

In the post I referenced above, the poster said that the log file would give
a "very verbose report of the search for freetds.conf." I didn't see a
search for it even with the log level set to 99, but that isn't my main
problem.

The thing that I really can't understand is why iodbctest doesn't work even
when I DO have the .freetds.conf file in my home directory and when the
unit tests seem to pass for the most part (as I explained before), but I get
this following output when I try to run iodbctest:

testuser@localhost:~$ iodbctest
iODBC Demonstration program
This program shows an interactive SQL processor
Driver Manager: 03.52.0205.0204

Enter ODBC connect string (? shows list): DSN=Employee
RADIUS;Uid=EmployeeRadius;Pwd=<password>;
src/tds/login.c: tds_connect: 127.0.0.1:1433: Connection refused
1: SQLDriverConnect =  Err 20009, Level 9, State 0, Server OpenClient, Line
0
Server is unavailable or does not exist.
 (1) SQLSTATE=HY000
2: SQLDriverConnect = Client unable to establish connection (1)
SQLSTATE=08001
1: ODBC_Connect =  Err 20009, Level 9, State 0, Server OpenClient, Line 0
Server is unavailable or does not exist.
 (1) SQLSTATE=HY000
2: ODBC_Connect = Client unable to establish connection (1) SQLSTATE=08001

Have a nice day.testuser@localhost:~$ ls -al ~/.freetds.conf
-rw-r--r--  1 testuser testuser 68 2005-08-12 16:10
/home/testuser/.freetds.conf

As you can see, it seems to have a blatant disregard for my ~/.freetds.conf
and /etc/freetds/freetds.conf files. My /etc/odbc.ini file looks like this:

;
;  odbc.ini
;
[ODBC Data Sources]

[Employee RADIUS]
Driver          = /usr/lib/odbc/libtdsodbc.so
Setup           = /usr/lib/odbc/libtdsodbc.so
Description     = Employee RADIUS Connection
Database        = <database>
Server          = myserver.mydomain.com
Port            = 1433
TDS_Version     = 7.0
;Servername     = MyServer

;[Default]
;Driver = /usr/lib/odbc/libtdsodbc.so

[ODBC]
Trace = 1
TraceFile = /tmp/odbctrace.log
Debug = 0
DebugFile = /tmp/odbcdebug.log

Even when I uncomment 'Servername' and put semicolons in front of 'Server',
'Port', and 'TDS_Version', the ODBC driver still tries to connect to
127.0.0.1 instead of trying to connect to the server I have defined in the
~/.freetds.conf and /etc/freetds/freetds.conf files.

In case it helps and you were wondering, FreeDTS was installed and
configured using Debian's 'apt'. The /etc/freetds/freetds.conf file and
freetds directory were set up after the package had been installed.
Therefore, I'm pretty sure that the configure options used during the build
point the assembly to /etc/freetds/freetds.conf for the config file.

Any ideas on where else it could be looking for the freetds.conf file or why
iodbctest fails but the unit tests generally pass?