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
On 27-11-2021 14:10, Mark Rotteveel wrote:
On 26-11-2021 10:10, Dmitry Yemanov wrote:
I'd appreciate if Mark could test scrollability from the Jaybird side
too (i.e. without fbclient involved), but the new protocol should be
supported for that.
I'm running into some odd behaviour. As soon as
On 26-11-2021 10:10, Dmitry Yemanov wrote:
I'd appreciate if Mark could test scrollability from the Jaybird side
too (i.e. without fbclient involved), but the new protocol should be
supported for that.
I'm running into some odd behaviour. As soon as I do a fetch_next or
fetch_prior, any
On 26-11-2021 10:10, Dmitry Yemanov wrote:
Mark et al,
Yes, I think that is perfectly acceptable for an initial version.
Scrollable cursors are a bit of an oddity anyway, but having
scrollable cursors in embedded access, but not in remote access is
IMHO less acceptable than bad performance.
Dmitry Yemanov wrote 27.11.2021 12:23:
I would consider adding a NO_BATCH flag (which is currently triggered using FOR
UPDATE syntax) to cursorFlags.
That would be useful in some cases. And if statements with "WHERE CURRENT OF"
condition also were somehow marked client libraries could force
27.11.2021 12:42, Mark Rotteveel wrote:
Yes, I think that is perfectly acceptable for an initial version.
Scrollable cursors are a bit of an oddity anyway, but having
scrollable cursors in embedded access, but not in remote access is
IMHO less acceptable than bad performance. As long as the
