FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

On Sun, 27 Mar 2011 20:38:05 -0400
Brian Bruns <brian AT bruns.com> wrote:

> Well, we store plenty of client properties in the freetds.conf.
> textsize, timeouts, client charset, etc...

Quite so.   The [global] section serves as a client-side
property section.  

When associated with a server, they do become client attributes for a
given server, yes.  But is that really useful?  Client encoding never
varies by server; I don't see why textsize and timeouts should,
either.  

(I was there, er, here when freetds.conf was invented.  I just think I
have a clearer understanding now.)

> Certainly, if the .conf had a database property set, the program could
> override it.  

Yes, with something like DBSETLDBNAME().  :-)

> If and when I find the need to connect to Azure, you can look for a
> patch from me, as sqsh and other clients will be hard pressed to act
> correctly without.

The ablility to set defaults in
freetds.conf can be useful, I agree.  By the same token, for sqsh to
implement its -D dbname option in an Azure database, ct-lib too will
need the ability to set the database name in the login packet.  

> dblib is not dead, just the organization in charge of extending it has
> changed.

Hear, hear, comrade!  

Just to re-iterate, a TDS 5.0 login packet has no dbname field; it's a
TDS 7+ feature.  Microsoft added the ability to set that field to
ODBC.  They never upgraded their db-lib beyond TDS 4.2, and hence never
needed extend db-lib in that way.  

The login packet also has the 0x40 option to require access to the
database to be permitted for the login to be accepted.  db-lib has no
way to set that bit on or off at present.  

Regards, 

--jkl