FreeTDS Development Group

["Varley, David(CBorn at Alcoa)" <David.Varley AT alcoa.com.au>]

Freddy's unit test for ODBC motivated me to try again to get unixODBC
working on Tru64. The CVS code doesn't want to build due to the older
autoconf tools they are using, so I went back to the 2.2.2 release. That
also has problems, fails trying to build sqp, but after working around that
(delete my flex and re-configure) it built ok.
The result gave me a working isql to test with, although it complains about
alignment problems on every result, so there will be a structure somewhere
that needs a pack pragma added...

Back to the unit test. Still doesn't work. Now as I have had troubles
getting the tests to pass against the default JDBC, I've been using one of
my own SQLServer 7 databases for testing. And the SRV entry in my PWD file
had the server's hostname, not the freetds.conf server name. After much
testing & tracing, I found that if I use the Server name from the
freetds.conf file instead, the ODBC unittest works fine, and passes. (Hooray
:)
But then I find the other unittests fail, can't get past the first tds login
test.

I figure it's probably something in the odbcinst.ini/ odbc.ini/ freetds.conf
configuration confusions, but I can't see where, and I'm puzzled that I can
get one or the other but not both working.

Here's what I get when SRV is cpro200 (the NT  server).
Why is tds_connect using the localhost address ?

compaq.cborn.com> ./t0001
odbctest
--------

connection parameters:
server:   'cpro200'
user:     'baker'
password: '????'
database: 'Bakes'
src/tds/login.c: tds_connect: 127.0.0.1:1433: Connection refused
Unable to open data source (ret=-1)
SQL error 08001 -- [unixODBC]tds_connect failed


If I set SRV to Bakes this test passes, but the others fail.
(Bakes is the entry for the server in odbc.ini and freetds.conf, as well as
the database name).

David