FreeTDS Development Group

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

> From: Thompson, Bill D (London)
> Sent: Thursday, April 14, 2005 6:12 AM
> 
> James,
> 
> The ct_options() implementation in Sybase is much more messy
> than I imagined.
> 
> It turns out that there is a TDS 5.0 message which corresponds
> to the ct_options() call.  

I had forgotten about that token.  

> It would also appear to be the case that these settings are
> NOT kept in line with actual active server settings.

Blech. 

> So, when you GET a setting using ct_options straight after
> connecting, before SETting any, they appear to be undefined.
> I tried this with the DATEFIRST setting. This should always
> have a value (between 1 and 7).  However ct_options returned
> zero as the value for this option, if I got it straight after
> connecting.  From this I deduce that you can only do a
> ct_options GET after a ct_options SET, if you hope to get a
> valid value.

Blech. Blech.  Agrees with the docs, though.  Not the most elegant part
of the library.  

> I'll carry on investigating, but I'm tempted to just implement
> the option that we require for DBD::Sybase, which I would
> implement issuing SET CHAINED/IMPLICIT_TRANSACTIONS commands.

Well, if you want it to work with Microsoft servers, the TDS 5.0 packet
type is obviously no use.  (It would be nice to support it for Sybase
servers, because it might allow some settings to be changed even in the
midst of reading a result set.)  

The goal, I think, should be to make the DBD::Sybase (and eventually
DBD::ODBC) unit tests work perfectly.  First up is transactions, even
though Michael pointed out a workaround.  

As things stand, the only reason DBD::Sybase works at all is that
autocommit mode is always on: every BEGIN TRAN is quietly ignored, and
every COMMIT elicits an error message from the server.  Obviously, a
ROLLBACK wouldn't work out so "favorably".  Even without looking, I'm
sure some tests are failing for that reason.  Even if they're not,
there're bound to be programs "out there" either failing or waiting to
fail....

For reference, here's a current result (FreeTDS CVS HEAD,
DBD-Sybase-1.05):

Failed 8/12 test scripts, 33.33% okay. 129/208 subtests failed, 37.98%
okay.
Failed Test    Stat Wstat Total Fail  Failed  List of Failed
------------------------------------------------------------------------
-------
t/autocommit.t    0   139     5    2  40.00%  4-5
t/exec.t         12  3072    17   12  70.59%  5-6 8-17
t/fail.t        255 65280    12    9  75.00%  4 6-7 10-12
t/main.t        255 65280    29   15  51.72%  21 23-29
t/multi_sth.t   255 65280    43   56 130.23%  12 14 16-43
t/place.t       255 65280    13   11  84.62%  6-7 9-13
t/xblk.t          0   139    62  112 180.65%  6-62
t/xblob.t         7  1792    11   13 118.18%  4 6-11

I guess FreeTDS is some kind of hand grenade.  You know, "Close only
counts in horseshoes and hand grenades." 

--jkl




-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information 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.