Skip to Content.
Sympa Menu

freetds - Re: unixODBC woes

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: "TDS Development Group" <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: unixODBC woes
  • Date: Thu, 5 Sep 2002 09:21:29 -0400


On Thu, 5 Sep 2002 13:54:43 +0800, Leon Brooks <leon AT cclinic.com.au>
wrote:

> Background: I'm researching the components needed to replace a small
> office's Windows workstations with thin (LTSP) clients. One requirement
> is that the installation be able to run MS-Access for a year or so,
> talking to MS SQl Server 7, while the application in question got a
> thorough Zopeing.
>
> So far, we have MS-Access running under WINE (local MDBs only) and also
> (including network connections to MS SQL Server) under Win4Lin.

[interesting story deleted]

> I grabbed, compiled and installed FreeTDS (0.53) with the
> --with-unixodbc option. It seemed happy to compile and install, but
> would not work with any of the configurations I could find or imagine. I
> presume that the [servername] entry in freetds.conf has to match the
> [DSNname] entry in odbc.ini, but the docs don't seem to define this
> anywhere. They (both unixODBC and FreeTDS) do speak of an interfaces
> file, which freetds.conf labels `obselete'.

Leon,

Wow. As you can tell from the User Guide, getting Access to work on Wine
with ODBC to connect to MS SQL Server 7.0 was *precisely* the objective of
the project. Oh, sorry, wrong universe, just kidding. ;) ODBC is not my
strength, but let me see if I can help....

The DSNname is how your ODBC apps know the server. It doesn't have to
match the FreeTDS [servername] entry as long as the [DSNname] entry
indicates what [servername] it's representing. It's a mapping, same as
[servername] maps to the host name of the server in freetds.conf.

The freetds.conf was introduced with 0.53; unixodbc might not know about
it. "interfaces" is an older way to describe a subset of the same
information that freetds.conf does. I don't think unixodbc cares whether
or not an interfaces file exists.

> I thought that perhaps freetds was broken, so I grabbed and compiled
> sqsh, telling it that SyBase lived at the --prefix I'd used for FreeTDS.
> I had to tweak the Makefile and config.h to get it compiled, but... one
> command and one password later, I was talking to the MS SQL Server
> through it.

Demonstrating that your freetds.conf is correct and your account is
valid....

> At this point, I'd like to know (1) if there's some magic thing I need
> to do to make unixODBC's isql work; and (2) what I need to do to bolt
> FreeTDS into unixODBC and have it work.

Mumble. You're quite right of course to aim at getting unixODBC's isql
working. Unless and until it does, we know for sure Access won't.

Definitely worth trying: use the latest FreeTDS snapshot. We're headed
for a release as early as next week. If you can't get that working with
unixODBC, the the ODBC geeks here will be all over you with questions.

> If I need to post debugging information, tell me what, how to get it if
> not obvious, and where to.

The FreeTDS logs will show you how far you're getting, and whether or not
FreeTDS's ODBC interface is being passed the right username+password. You
could do that readily, without compiling or installing anything else.

BTW, even though I recommend 0.60 (the nightly snapshot), I don't want the
documentation to mislead you. If you're working with 0.53, see
http://www.freetds.org/userguide.orig/. The regular user guide describes
0.60.

HTH.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page