Skip to Content.
Sympa Menu

freetds - RE: [freetds] Re: Re: RE: freeTDS unixODBC...Which one isn't work ing

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Re: Re: RE: freeTDS unixODBC...Which one isn't work ing
  • Date: Mon, 5 Jan 2004 16:56:07 -0500

> From: Daughterson, Adam [EPM/BOU/MMI]
> Sent: January 5, 2004 3:33 PM
>
> I had to compile/configure unixODBC first (to use isql for
> testing) and couldn't find any reason
> to pass any arguments to the ./configure && make && make install.
>
> Then I ran ./configure --with-unixodbc --with-tdsver=8.0
> and let it install freetds in the default /usr/local prefix.

That should be:

--with-unixodbc=DIR

where DIR is the unixodbc PREFIX. I don't know the effect of not providing
DIR. Probably, the regular autodetection search remains in effect, witness
that you relied on unixodbc's default PREFIX and were able to compile
FreeTDS.

> I edited /usr/local/etc/freetds.conf and tested with tsql. OK so far.
> /usr/local/etc/dumpo(for debugging) is the glad recipient of
> TDSDUMPCONFIG.
> After tsql, I get lots of nice info about the successful
> connection to DB.

So far, so good.

> Now to experiment, I selectively move the odbc.ini and
> odbcinst.ini around
> to ~, and /usr/local/etc (among other places), it 'works' in
> both ~, and
> /usr/local/etc. ('works' because isql gripes that there
> aren't any data
> sources by that name when the odbc*.ini files are not in ~, or
> /usr/local/etc)

Again, I'm no expert with ODBC. I'm just trying to follow my own
directions. (!)

I think you should expect /usr/local/etc/odbc.ini to be the right place.
I'm not sure, however, that the file is correctly set up. Would it be
accurate to say you're aiming at an ODBC-only configuration? That's how it
looks to me, because you're using "Server" (not Servername).

> root@USBOU1-DHDLINUX:/usr/local/etc# cat odbc.ini
> [ODBC Data Sources]
> esp_ms_sql = MS SQL Server
>
> [esp_ms_sql]
> Driver = /usr/local/lib/libodbc.so
^^^^^^^^^^^^^^^^^^^^^^^^^
Not needed if same as [default]
> Description = MS SQL Server
> Trace = No
> Server = usbou1-scallog
^^^^^^^^^^^^^^
Can you "ping usbou1-scallog"?
Because Server takes a network name.
> Port = 1433
> Address = 155.177.99.17
^^^^^^^^^^^^^
Not necessary, afaik.
> TDS_Version = 8.0
> UID = esp_it
> Database = esp35_it
> [Default]
> Driver = /usr/local/lib/libodbc.so
^^^^^^^
I really think this should be:
Driver = /usr/local/lib/libtdsodbc.so

per our documentation. Either that, or we change the UG. Likewise for
odbcinst.ini, although I don't understand that file's role.

> I tried using /usr/local/lib/libtdsodbc.so as the driver in
> both ini files
> and it immediately errors out with Unable to SQLConnect.

Can we see the output of:

$ isql esp_ms_sql username password

Really, that should connect, or at least populate your TDSDUMP file, as long
as usbou1-scallog is the name of the machine hosting the database server.

If that doesn't work, I'd be interested to try the old-fashioned way, with
an odbc.ini like this:

[ODBC Data Sources][1]
esp_ms_sql = MS SQL Server

[esp_ms_sql]
Description = Adams Recalcitrant Server
Trace = No
Servername = esp

[Default]
Driver = /usr/local/lib/libtdsodbc.so

freetds.conf:

[esp]
host = usbou1-scallog
port = 1433

And then:

$ export TDSDUMP=stdout
$ isql esp_ms_sql username password


I'm sorry to take you over the same road again, Adam, but one of us is
surely overlooking something. Getting a dump file is usually just not this
hard.

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the original
message. Please note that we do not accept account orders and/or instructions
by e-mail, and therefore will not be responsible for carrying out such orders
and/or instructions.





  • RE: [freetds] Re: Re: RE: freeTDS unixODBC...Which one isn't work ing, Lowden, James K, 01/05/2004

Archive powered by MHonArc 2.6.24.

Top of Page