FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Wed, 30 May 2001, James K. Lowden wrote:

> I vote for [global] cf. Samba if it's still up for debate.  Since James's 
> main
> concern was having a database by that name, and the more like Samba it is, 
> the
> better.  For instance, Samba uses the name "workgroup" where you've opted 
> for "nt
> domain".  I think the latter is clearer, but might Samba alignment pay off 
> later?

I was kinda partial to global for those reasons myself, but I'll go with
what the group thinks as a whole.  

Re, nt domain, workgroup is not entirely context free and is more or less
a holdover from the WINS stuff. Very confusing for new users. Our options
are going to be drastically different from samba, so even though we can
follow that syntactically the amount of overlap in function is too close
to zero to worry about making the same.

> > [global]
> >         tds version = 5.0
> >         initial block size = 512
> >         swap broken dates = no
> >         swap broken money = no
> 
> I like this very much.  What is the relationship of the values in [global] 
> to the
> environment variables?  Can we do away the environment variables altogether?

Very possibly.  Of course, just don't set them and you're all set.  They
will remain as options for a while.

<rant> I started to list the process by which freetds finds the setting
values, starting with programatic settings, env variable, the multiple
places for freetds.conf and interfaces files, and finally the compile time
defaults...It was huge!  We will be simplifying this for sure in upcoming
releases. </rant>

> Hi Brian,
> 
> I think this is marvelous, by the way, an important feature.  What's the 
> right thing
> to say here?  Attaboy?  Thank you for tackling this.
> 
> A few thoughts, some whacky, no doubt, for your esteemed consideration:
> 
> 1.    FreeTDS should mimic the behavior of the native client insofar as 
> possible, and
> require as little of the user as possible.  For instance, why should the 
> library need
> a {try | don't try} option for domain/server authentication?  Why not: Just 
> Try?  The
> MS client uses trusted logins for any connection for which the client 
> doesn't
> explicitly set a username.  And it definitely *should* be per-connection.  
> The
> trusted login is a kind of default environment; overriding it with a 
> username is
> useful to alter the privileges of a particular application or interactive 
> session.

domain auth/server login is apparently a setting of the ODBC driver on
windows. It gets *really* messy trying to figure this stuff out by
trial. 
 
> 2.    Can I say I don't like specifying the TDS protocol version?  I think 
> the user
> should specify Sybase/MS and the server version, and FreeTDS should pick 
> the best TDS
> version.  Is there any reason anymore not to run the highest supported TDS 
> version
> for a given server environment?

In concept, a good idea, however, TDS 7 is currently broken (I think) on
bigendian platforms for instance.  And even if bugs are not a problem, you
may prefer to use TDS 4.2 in low bandwidth applications (not unicode,
everything is half the size).  And most importantly, helping the user
isolate under which version(s) he has a problem.  Perhaps better and more
documentation is the answer...like:

# These are the only configurations that work!
# Sybase 4.9 and below: 4.2
# Sybase 10.x and above: 4.2 or 5.0
# MS SQL Server 6.5 and below: 4.2
# MS SQL Server 7.0 and above: 4.2 or 7.0
# MS SQL Server 2000 and above: 4.2, 7.0, or 8.0 (when supported)
# MS SQL Server from big endian platforms: 4.2
        tds version = 4.2

> 3.    I suggest we dump interfaces completely.  Sybase did, Microsoft did.  
> It's a
> dodo.  I'll send you some perl (or C++, if need be) to convert an 
> interfaces file to
> a skeleton freetds.conf if you think it could be incorporated into the 
> FreeTDS
> installation.

I would like that (perl is fine...we won't have to worry about
building it).  Let's do this: 

1) Release notes should describe how to convert interfaces to
   freetds.conf. 
2) We will not search $SYBASE/freetds.conf but instead only look for
   ~/.freetds.conf and a freetds.conf under the --prefix location
3) We update the documentation post-0.52 to reflect the new scheme
4) During the next development cycle trim the search for the interfaces
   file to look only in $SYBASE/interfaces as a fallback.

> 4.    If we dump interfaces, we can do away with $SYBASE, too.  Why not 
> replace it
> with $FREETDS, pointing to freetds.conf?  If ~/.freetds.conf is honored 
> before
> $FREETDS/freetds.conf, we can dump all the environment variables.

Why not just use the --prefix from configure and be done with the
environment variable entirely.  It was always a pain in the ass, even
under Sybase.  Speaking of dump, I forgot a couple of settings:

[myserver]
        dump file = /tmp/freetds.log
        debug level = 10

> In sum, freetds.conf is flexible enough to incorporate all the environment 
> variables
> (including $SYBASE) and the interfaces file.  It should contain what the 
> user knows
> or can ascertain about his environment.  Authentication should be 
> per-connection,
> relying on trusted logins in the absence of a username.

The basic problem with $SYBASE is that is would be useful for finding your
libs but by that time your code is running so it has already had to find
the libs!  chicken and egg...$SYBASE is on the way out

This whole thing should help make life easier for people making rpms and
debs of freetds.

> and call it, oh, "The Registry", and hide the data in it and charge 
> everyone for
> developing two brain-dead APIs to it?   Then, you could make it 
> mind-numbingly
> complicated and hard to use, embed all sorts of non-portable hardware stuff 
> in it,
> and make the thing so fragile everyone will treat it with kid gloves, while 
> you get
> credit for a brilliant visionary centralized configuration strategy!  No?  
> Well, just
> a thought.  World domination is good for the winners, you know.

We could make it a gconf plugin ;-)