Re: Using DBLIB With Azure

My two cents, and not that my opinion carries any weight any more, but...

I would think the most natural place for this is the freetds.conf (and
odbc.ini, or DSN connection string).  It requires no API extension,
and if Azure, as stated, doesn't allow "use <database>" syntax, then
every Azure database must have a database as part of the login, we are
just pushing the burden on the programmer by implementing
DBSETLDATABASE(), not to mention it is dblib() specific.

Besides we already have an "asa database" option, which is a variation
on the theme.  Maybe calling it "initial database" or "default
database" would be a little clearer.  Servers that support changing
databases, can use the feature to enforce a initial database
selection, and Azure can get what it needs.

Maybe I've misunderstood the issue, and besides I'm all talk and no code. ;-)

Brian

2011/3/27 James K. Lowden <[email protected]>:
> On Sun, 27 Mar 2011 09:03:58 -0400
> Ken Collins <[email protected]> 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
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>