FreeTDS Development Group

[Ken Collins <metaskills AT me.com>]

OK, just had time to come back to this.

>> Azure does not have a notion of "USE ..." or has a way to specify a 
>> default database with the user account
> 
> https://github.com/rails-sqlserver/tiny_tds
> 
> OK, I think I finally get the picture.  
> If I understand aright, the TinyTds user -- an elf or gnome, perhaps? -- 
> should be able to say something like this:
> client = TinyTds::Client.new(:username => 'sa', :password => 'secret', 
> :dataserver => 'mytds_box', :database = 'mydb')
> 
> and you want to know how to deal with 'mydb'.  
> Simple: dbuse().  
> 
> You're not obliged to use only one db-lib function when the connection is 
> established.  Just call dblogin(), dbopen(), and dbuse(), in that order.  
> Job done.  

Job not done. I have used dblogin(), dbopen() and dbuse() in that order since 
TinyTDS started.
https://github.com/rails-sqlserver/tiny_tds/blob/master/ext/tiny_tds/client.c#L242
https://github.com/rails-sqlserver/tiny_tds/blob/master/ext/tiny_tds/client.c#L257
https://github.com/rails-sqlserver/tiny_tds/blob/master/ext/tiny_tds/client.c#L264

That process is exactly the problem. Like I said, Azure does not have a 
notion of "USE..." and that is what dbuse() does.

> If you really, really, really want to, you could extend db-lib.  It's a 
> mini project: 
> 
> 1.  add dbname to TDSLOGIN
> 2.  add case to set dbname in dbsetlname
> 3.  add macro DBSETLDBNAME
> 4.  refer to TDSLOGIN::dbname when the structure is copied to 
> TDSCONNECTION.  
> 
> An alternative would be to add a new function, dbopendb(), that would take 
> three parameters instead of two.  

That sounds promising. Is this something I would be able to do when people 
compile my ruby c-extension? I did not think C was so dynamic in the sense if 
there was no public header from a FreeTDS install that I would be able to 
monkey patch an addition to a library/project that was purposely hidden by 
FreeTDS. Am I wrong on that? If not, would you consider a patch if I 
submitted one for the release?

> Could be done, minorly useful.  To a db-lib program, it's hard to see much 
> advantage to 
> 
>       DBSETLDB("mydb")
> over
>       dbuse("mydb")
> 
> especially because dbuse() can fail, keeping the connection viable.  

I agree when connecting to non-azure DBs but that is not the point. Azure is 
made so there is no "USE.." and it is explicitly designed so that if you do 
not connect to the right DB, there is no connection, did I mention that? :)

> If you put the dbname in the login packet, you invite the ODBC problem -- I 
> say problem, but others might say feature -- of disallowing the connection 
> because the database name is wrong/unavailable. It's one of my (least) 
> favorite error messages: you can't login because the username/password is 
> invalid OR because you're not granted access to the database.  Such, such 
> are the joys of troubleshooting.  Nothing like ambiguity with your coffee.  

I agree with you, but that is moot. Azure has no "USE.." feature and is 
explicity designed around that "feature" of disallowing the connection 
because the database name is wrong/unavailable.

> HTH (this time). 

Immensely! Hopefully one more round will get the ball rolling again.
Thanks in advance and I look forward to anymore feedback.

- Ken