FreeTDS Development Group

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

On Sun, 27 Mar 2011 09:03:58 -0400
Ken Collins <ken AT metaskills.net> wrote:

> Attached is a diff/patch that I am able to confirm works for me and
> allows me to connection with TinyTDS. This means any db-lib can not
> use DBSETLDBNAME to do the same. 

Hi Ken, 

Applied.  Thank you for the patch.  Yes, it will be included in the
next release, absent unforeseen difficulties.  

> > DBSETLDBNAME() is the most natural way to extend db-lib to include
> > the database name in the login packet.  

I want to explain "most natural" for the record, because the last time
db-lib was extended was during the late Mesozoic.  

We wanted to set the dbname field in the TDS 7+ login packet because
Microsoft requires it for Azure logins.  (That is consistent with ODBC
logins.)  We could have added another dbopen() -- say, dbopendb() -- or
we could extend the LOGINREC.  We chose the latter.  

The LOGINREC holds things about the *client* that the server will want
to know at login time.  In dbopen()

        DBPROCESS *dbopen(LOGINREC login, char * server)

login describes the client (in an in-memory structure) and server
describes the server (in freetds.conf, basically).   By putting dbname
in the LOGINREC, we're saying it's a client attribute.  Every
connection created with a LOGINREC will use the same database.  To
change databases, the program can modify the LOGINREC or call dbuse
() if the server permits it.  

If we had modified the server side of dbopen(), we'd have a much less
flexible arrangement, because we'd need to define a different server
for every dbname.  If we'd modified dbopen() itself, we'd be admitting
we don't know whether the dbname is a server or client attribute.  But
it's part of the login packet, and the LOGINREC is basically a proxy
for the login packet.  So we put it there, where it belongs.  In its
most natural place.  

--jkl