FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

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

--jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential and is intended only for the use of the person(s) named
above. If you are not the intended recipient, or an employee or agent 
responsible
for delivering this message to the intended recipient, any review, 
dissemination,
distribution or duplication of this communication is strictly prohibited. If 
you are
not the intended recipient, please contact the sender immediately by reply 
e-mail
and destroy all copies of the original message. Please note that we do not 
accept
account orders and/or instructions by e-mail, and therefore will not be 
responsible
for carrying out such orders and/or instructions.  If you, as the intended 
recipient
of this message, the purpose of which is to inform and update our clients, 
prospects
and consultants of developments relating to our services and products, would 
not
like to receive further e-mail correspondence from the sender, please "reply" 
to the
sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New 
York,
NY 10105.