FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

>
> 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
- t0002
- t0008
- t0016
- t0017
- bcp

only with Sybase
- t0021
- hang

only with MS
- null2
- rpc
- setnull
- t0004
- t0005
- t0007
- t0019
- t0022
- text_buffer

t0002 and t0008 tests fail with same errors:

t0002
Failed: Expected a row (t0002.c:160)
Failed: dbnextrow returned BUF_FULL (-3).  Fix dbclrbuf.

t0008
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
>> stack:
>>
>>      tds_peek()
>> 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.

freddy77