Re: Using DBLIB With Azure

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