[freetds] errors from dblib
freddy77 at gmail.com
Mon Apr 20 11:20:32 EDT 2009
> Yes, only errors
>> It looks like we're more compatible with Sybase than Microsoft....
I think so, we can divide tests that fails with vendor libraries as
tests that fail with both versions
only with Sybase
only with MS
t0002 and t0008 tests fail with same errors:
Failed: Expected a row (t0002.c:160)
Failed: dbnextrow returned BUF_FULL (-3). Fix dbclrbuf.
Read a row of data -> 48 row 048
dblib failed for t0008.c, dbnextrow1
it seems row buffering doesn't work so well... but I think it's easy to fix it.
>>> You can see from attached files. I got dbsqlok fixed for timeout test
>>> removing these lines
>>> marker = tds_peek(tds);
>> I spent some time looking at this. I'm not sure we can remove those rows.
>> The code is deeply confused by the cancel packet. After the CANCEL is
>> sent, the server acknowledges it. But first it sends the pending data.
>> dbsqlok() sees the ROWFORMAT2 token and returns success.
>> With Microsoft/Sybase, does dbsqlok() fail? (I assume yes.)
> Yes, both fails
>> The error isn't tds_peek(). The error is in tds_goodread(). It should
>> wait for the cancel acknowledgement, wasting any pending data. Here's the
>> calls tds_get_byte()
>> calls tds_read_packet()
>> calls goodread()
>> calls tds_goodread()
>> calls tds_send_cancel() on timeout
>> and continues to wait
> I always though tds_get/peak/read as low level. The layer is Client
> libraries <-> Token Processing <-> Reading processing. Client
> libraries should IMHO never call tds_peek/tds_read and similar. Token
> processing handle correctly cancellation. It's also difficult to
> handle cancellation in low level cause you don't know exactly the
> state of the connection. This cause usually low level reading
> functions are called by token processing which perhaps readed already
> a partial packet or token so you don't know if you are in a middle of
> some data.
as change doesn't break any tests I committed it.
More information about the FreeTDS