Re: Using DBLIB With Azure
"James K. Lowden" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[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