FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

Title: RE: [freetds] Re: freetds.conf?

"I just don't know if the interfaces file can carry us as far as we need to go."

Not to worry. 

I just prepended your example verbatim to my SQL.INI (what Sybase calls the interfaces file in NT).  ISQL happily ignored what it didn't need and connected per usual. 

Anybody want to try that on a Sybase+Unix box?  I'll bet a bunch of bits the Sybase libraries ignore what they don't recognize.  They kinda hafta, after all: who would they complain to? 

No question: parseable comments or a separate .conf file runs zero risk of interfering with a working interfaces file.  I just think that risk is small and more than offset by the advantages (to the user and to the programmer) of a single configuration vehicle. 

Only trying to be helpful, of course. 

-----Original Message-----
From: Brian Bruns [mailto:camber AT ais.org]
Sent: November 2, 2000 6:14 PM
To: TDS Development Group
Subject: [freetds] Re: freetds.conf?

My thinking was to keep the per server stuff in the interfaces files and
the global settings for the whole library freetds.conf. 

I dislike using commented lines, and now I'm wondering if perhaps making a
clean break isn't justified.  In the absence of the freetds.conf file we
could fall back to the interfaces file with it's limited configurability. 
I'm envisioning a lot of configurable parameters, some global, some server
specific, some version specific.  For instance:

[global]
home=/usr/local/freetds
dumpfile=/tmp/freetds.log

[tds5.0]
blocksize = 512

[tds7.0]
blocksize = 4096

[mysybserver]
host = 127.0.0.1
tdsver = 5.0
port = 4000

[mysqlserver]
host = ntbox.mydomain.com
tdsver = 7.0
port = 1433
datehack = yes   # turn on big endian date fix hack required by SP1

I just don't know if the interfaces file can carry us as far as we need to
go.

Brian

On Thu, 2 Nov 2000, Scott C. Gray wrote:

> On Thu, 2 Nov 2000, Lowden, James K wrote:
>
> > Brian,
> >
> > Rather than a freetds.conf file, might it be simpler to extend the
> > interfaces file?  I think it can have pretty much anything in it; the
> > libraries probably look for what they need and skip the rest.  I think the
> > run-time parameters are easier to manage if they're all in one place. 
>
> I have added to my (someday-to-be-released-if-i-can-scrape-other-
> things-off-my-page) version of the tds library (well, actually
> my new cs-library) some extensions to configure freetds in
> comments.  For example, you can override the protocol
> by doing:
>
>    #PROTO: tds7.0
>    SERVER
>       query tcp ether server 5000
>
> where the #PROTO line will override the 'ether' setting for this
> and all following entries. Generically, my parser looks for:
>
>    #OPTION: value[,value ...] [OPTION: value[,value...] ...]
>
> This allows server entries to be consistant with the Sybase model,
> but freetds can get hints as well.
>
> -scott
>
> --
> Scott C. Gray <gray AT voicenet.com>     "my keybard is brken"
>        http://www.voicenet.com/~gray/sqsh.html
>
>
>
> ---
> You are currently subscribed to freetds as: [camber AT ais.org]
> To unsubscribe, forward this message to $subst('Email.Unsub')
>

---
You are currently subscribed to freetds as: [LowdenJK AT bernstein.com]
To unsubscribe, forward this message to $subst('Email.Unsub')