27.11.2021 17:28, Mark Rotteveel wrote:
I'm running into some odd behaviour. As soon as I do a fetch_next or
fetch_prior, any subsequent fetch ignores the fetch direction, and
applies fetch_next (or fetch_prior).
Correction: it behaves as fetch_next (or fetch_prior) for the amount of
rows that was fetched in the last fetch (or at least some number of rows
buffered on the server).
I can understand needing to take into account the client-side buffer,
but I don't think that I should take into account any rows that the
server has buffered.
If you requested N rows from the server but now switching to the
different fetch operation before getting all those rows, I expect the
client to receive (and discard) the remaining part of the requested rows
before sending the new opcode. This is what fbclient does currently.
However, I can see the point in letting the server to cleanup the queue
instead of the client. I will give it a try.
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
