Re: Using DBLIB With Azure

2011/3/27 Brian Bruns <[email protected]>:
> 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.
>

Agreed and I though freetds.conf would work already...

> 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.
>

Do not confuse "asa database" with "database". "asa database" is
related to server installation, similar to Microsoft instance concept.

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

bye
  freddy77

> 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
>>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds