On 28-11-2021 12:55, Dimitry Sibiryakov wrote:
Dmitry Yemanov wrote 28.11.2021 12:51:
28.11.2021 14:47, Dimitry Sibiryakov wrote:
RDB$DB_KEY for the current record as well.
It's not a property of the cursor. Consider joins, unions, procedures,
views, etc.
It is a property of a current
Dmitry Yemanov wrote 28.11.2021 12:51:
28.11.2021 14:47, Dimitry Sibiryakov wrote:
RDB$DB_KEY for the current record as well.
It's not a property of the cursor. Consider joins, unions, procedures, views,
etc.
It is a property of a current record the same as position. It is ok to return
Dmitry Yemanov wrote 28.11.2021 12:45:
That would be useful in some cases. And if statements with "WHERE CURRENT OF"
condition also were somehow marked client libraries could force cursor
position synchronization before executing them.
I'd expect FOR UPDATE to still disable batching even
28.11.2021 14:47, Dimitry Sibiryakov wrote:
RDB$DB_KEY for the current record as well.
It's not a property of the cursor. Consider joins, unions, procedures,
views, etc.
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Dmitry Yemanov wrote 28.11.2021 12:42:
Then we may support both "current position" and "total row count" in getInfo(),
RDB$DB_KEY for the current record as well.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 28-11-2021 12:22, Dmitry Yemanov wrote:
We don't have anything like this. Theoretically, we could extend
IRecordSet with something similar (although it would also require a
protocol change), but the question is whether it's really needed.
Personally, I don't see it useful per se. If users
27.11.2021 15:04, Dimitry Sibiryakov wrote:
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
28.11.2021 14:37, Dimitry Sibiryakov wrote:
And it doesn't need to be a dedicated method of IResultSet. Something
generic and easily extendable like IResultSet::getInfo() would be enough.
Then we may support both "current position" and "total row count" in
getInfo(), letting the client
Dmitry Yemanov wrote 28.11.2021 12:22:
Theoretically, we could extend IRecordSet with something similar (although it
would also require a protocol change), but the question is whether it's really
needed. Personally, I don't see it useful per se.
It could be useful for client-side caching
28.11.2021 14:02, Mark Rotteveel wrote:
Is there a way to determine at which row the cursor is currently
positioned? JDBC has the ResultSet.getRow()[1] method which is
documented as: "Retrieves the current row number. The first row is
number 1, the second number 2, and so on."
This is not
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.
28.11.2021 13:11, Mark Rotteveel wrote:
In other words, it looks as if Firebird when asked for 4 rows, will
return 4 rows and *also* buffer 4 more *on the server*, and return those
unconditionally on the next fetch.
Looks right, although weird I didn't notice that during the testing.
To be
On 28-11-2021 08:22, Dmitry Yemanov wrote:
27.11.2021 17:28, Mark Rotteveel wrote:
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
13 matches
Mail list logo
