Re: errors from dblib
Frediano Ziglio <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
> > 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 _______________________________________________ FreeTDS mailing list [email protected] http://lists.ibiblio.org/mailman/listinfo/freetds