FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il giorno mer, 21/09/2005 alle 17.47 -0400, Lowden, James K ha scritto:
> > From: Frediano Ziglio
> > Sent: Wednesday, September 21, 2005 3:31 PM
> > 
> > Il giorno mer, 21/09/2005 alle 10.38 -0400, Lowden, James K ha
> > scritto:
> > > > From: Christos Zoulas Sent: Wednesday, September 21, 2005 8:29
> > > > AM
> > > > 
> > > > | Unicode data in a Unicode-only collation or ntext data cannot
> > > > | be sent to clients using DB-Library (such as ISQL) or ODBC
> > > > | version 3.7 or earlier.
> > > > 
> > > > Maybe we should change our login packet to tell MSSQL that we
> > > > support Unicode even with tds 7.0?
> > > 
> > > The message is sent if the login packet does not set the "I'm an
> > > ODBC driver" bit in the options field.  Setting it on (as we used
> > > to) breaks db-lib semantics.  So the behavior is "right" for
> > > programs that expect, say, NOT NULL to be the default nullability
> > > of a column in a CREATE TABLE statement.
> > 
> > This is a longstanding issue. The problem is that mssql refuse to
> > return unicode to dblib and dblib have different defaults. The
> > question is: is there a way to connect saying "I'm odbc" and than
> > say "I want dblib settings"? If so we could connect trying to tell
> > that we are odbc and then change settings. SET ANSI_NULL does not
> > suffice ?
> 
> http://msdn.microsoft.com/library/en-us/tsqlref/ts_set-set_1vqe.asp
> http://msdn.microsoft.com/library/en-us/xmlsql/ac_openxml_759d.asp
> 
> Yes, we could do that.  We could connect as an ODBC driver and send SET
> ANSI_DEFAULTS OFF.  SET ANSI_NULL is not enough, but SET ANSI_DEFAULTS
> probably is.  It would work sometimes.  I'm not sure it would prevent
> the cited message.  
> 
> The only worry I'd have is complexity: as of now, our login packet
> sequence looks pretty much like Microsoft's.  If we bend it to do
> something clever, we open the door to compatibility problems with
> different servers.  
> 
> Before we "fix" this, I want to know what we're really trying to do.
> The goal of "make a db-lib just like Microsoft's" is clear.  The goal of
> "make a db-lib that does things Microsoft's can't" needs careful
> examination, IMO.  
> 
> For instance, there's no problem for an application to turn on most
> ODBC-ish features: they can use the SET statement.  Some things, such as
> FOR XML cannot afaik be solved that way; you have to have declared
> yourself as ODBC at login.  But I'm not sure.  
> 
> If all such problems can be solved with SET, I don't see that we should
> alter the db-lib login packet.  
> 

Very good. If I remember when you connect with dblib profiler let you
see settings for dblib. I will try to do some tests. About compatibility
I don't think is a stop-over. tds 7+ is supported only in mssql and we
already issue some SET statement after connect (I would remember that
server reply "I'm Microsoft SQL Server" just after login).

So a small roadmap:
1- check with sql profiler settings using odbc and dblib
2- extract all queries to test every single option (James, have you some
suggestions?)
3- change dblib to say "hey, I'm odbc" and change options just after
login
4- test all queries above to see if dblib behave as expected
5- test if unicode/xml work

Do you agree with me?
We could do a unit test for point 5...

freddy77