FreeTDS Development Group

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

> From: Frediano Ziglio
> Sent: Thursday, September 22, 2005 9:11 AM
> 
> 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.
> > 
> > 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
> 
> 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?

I agree with your roadmap, and I would be willing to do some
investigation and compatibility testing.  My only problem: I'm not
convinced it's necessary.  

I assert any db-lib application can "SET ANSI_DEFAULTS ON" and go its
merry way.  If someone can show me a situation where 

1.  that's not true, or
2.  it wouldn't be necessary with Sybase

then I would agree to help carry out your plan.  

At the very least, I'd like to be able to put in the release notes "We
changed db-lib to be partly ODBC-compliant because X works now and
didn't before."  

Remember Hippocrates.  I'm very concerned about painting ourselves in a
corner: we could easily change a default behavior, not notice it in
testing, and break existing applications.  

Thank you for all your hard work, Freddy.  

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