Skip to Content.
Sympa Menu

freetds - Re: [freetds] Connection to SQL2000 - Unicode data in aUnicode-onlycollation

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Connection to SQL2000 - Unicode data in aUnicode-onlycollation
  • Date: Thu, 22 Sep 2005 15:11:17 +0200

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






Archive powered by MHonArc 2.6.24.

Top of Page