[freetds] Connection to SQL2000 - Unicode data in aUnicode-onlycollation
freddyz77 at tin.it
Thu Sep 22 09:11:17 EDT 2005
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 ?
> 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
3- change dblib to say "hey, I'm odbc" and change options just after
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...
More information about the FreeTDS