Re: issue with connecting ms sql azure

"James K. Lowden" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
On Thu, 29 Sep 2011 17:46:30 -0700
Andy Qian <[email protected]> wrote:

> By tracing TDSDUMP info of connecting to other version ms sql server,
> I found it looks like that DBD::Sybase always logins to master
> database firstly, and then switches to the database specified in the
> dsn string by executing "use $database" statement.

To use Azure in Perl, you have to do one of two things:

1.  use DBD::ODBC, or
2.  hack FreeTDS's ct-lib & DBD::Sybase

As you may know, DBD::Sybase uses Client-Library, a/k/a ct-lib.
ct-lib's ct_connect() function takes a server name only, no database
name.  As you found out, the server initially connects the user
to the master database, then changes to the user's database, as
determined by the user's default database on that server.  If another
is wanted, the client application can change it.  AFAIK there's no
ct-lib connection setting or function to change the default database;
the application simply sends "use <dbname>".  

For those following along at home: "use <dbname>" comes too late for
Azure. Azure has no (or, at least, denies logins to) the master
database.  The client must specify the database name at the time
when logging in.  

How does ODBC do it?  ODBC sets the dbname in the login packet, which
the server honors.  

When someone else wanted to use db-lib with Azure, I added a feature to
the LOGINREC structure that lets the user set the dbname before calling
dbopen().  The effect is to set the dbname in the login packet,
something db-lib wouldn't otherwise do.  

To make it work in ct-lib, you'll have to do something similar.  Then,
once there's a way to set the dbname in a ct-lib login packet, you'll
have to modify DBD::Sybase to DTRT when the dbname appears in the
connection string.  

Just a small matter of programming.  

--jkl
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.