FreeTDS Development Group

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

Title: freetds.conf?

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. 

My suggestion, FWIW: have a psuedo-server entry to hold FreeTDS defaults, and a line for each server that can override them.  Finding a "plain" interfaces file would cause FreeTDS to revert to compile-time defaults. 

Notional example:

_FREETDS_       # global defaults
        opt1 opt2 opt3 opt4 etc.

myserver
        query tcp ether 127.0.0.1 4000
        master tcp ether 127.0.0.1 4000
         TDS    opt1 opt2 opt3 opt4     #server-specific options

This way, when you add a server you can set the TDS options at the same time.  Ditto when you upgrade one. 

I know the psuedo-server entry will work, because "_FREETDS_" would represent a never-used server name to the library.  FreeTDS might not be ready for a per-server line right now (I don't know how FreeTDS reacts to two simultaneous clients setting different TDSVER values for two different connections), but it's a logical need. 

I think extending the interfaces file in this way is very unlikely to interfere with anything Sybase will do. 

Not that I'm writing the code, of course.... 

--jkl

-----Original Message-----
From: Brian Bruns [mailto:camber AT ais.org]
Sent: November 1, 2000 9:31 PM
To: TDS Development Group
Subject: [freetds] large query redux

Ok, this large query thing is still driving me crazy.  Here's the senario
with SQL Server 7.0 GA release.  The client (freetds ctlib or dblib)
requests a default packet size of 512.  SQL Server responds with a
environment change from 4096 to 512 and all queries are sent with a block
size of 512 and everything works.  This doesn't jive with what has been
reported on the list for SQL Server, so I'm wondering if MS has changed
the behaviour in service packs to 7.0 to force a larger block size on the
client. If so, the current code in CVS should work against both the GA
release and SP1+.

So can someone with the large query problem and 7.0 test the current CVS
code and report back?  I'm anxious to have this thing settled. 

I'm also considering creating a freetds.conf file to store defaults that
we are using environment variables for now and more, such as protocol
version, trace file locations, tcp port numbers, default charset, default
language, and initial block size.  It's a bit of a departure from the
sybase way of doing things, but unless I hear otherwise, expect it in CVS
after the 0.51 release.

Brian

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