28.04.2022 14:31, Mark Rotteveel wrote:
I notice that if I get the INF_RECORD_COUNT with op_info_cursor before
the first fetch, I will get the record count, but the subsequent fetch
will fail with a Dynamic SQL Error; SQLDA error; Data type unknown; at
SQLVAR index 0 [SQLState:07002, ISC
On 22-04-2022 17:51, Dmitry Yemanov wrote:
22.04.2022 14:49, Mark Rotteveel wrote:
I was wondering if this - fetching rowcount of a scrollable cursor -
was already implemented. If so, how do I get it? And if not, when can
I expect it to be implemented?
PR #7083, was left for review but not
22.04.2022 14:49, Mark Rotteveel wrote:
28.11.2021 14:45, Mark Rotteveel wrote:
3) "row count" makes it possible to know the position after
fetchLast() and everything else could be calculated locally by the
client library, thus making the server-supported "current position"
totally
On 08-12-2021 10:13, Dmitry Yemanov wrote:
28.11.2021 14:45, Mark Rotteveel wrote:
3) "row count" makes it possible to know the position after fetchLast()
and everything else could be calculated locally by the client library,
thus making the server-supported "current position" totally
On 2021-12-20 11:51, Dmitry Yemanov wrote:
Mark et al,
Looked at it again, and being able to get the total row count will
work
for me. Is this information already available, or does this still need
to be implemented?
What would you expect from the "row count" requested for a
non-scrollable
20.12.2021 13:58, Dimitry Sibiryakov wrote:
Even non-scrollable cursors can know total number of records if plan
SORT is used
Sort may be hidden inside other execution nodes, so it's not always as
easy to know. I'd rather avoid returning (or not) info depending on the
query plan.
or
Dmitry Yemanov wrote 20.12.2021 11:51:
What would you expect from the "row count" requested for a non-scrollable
cursor?
Even non-scrollable cursors can know total number of records if plan SORT is
used or they are fetched to the end but I think that isc_infona is the right
answer in all
Mark et al,
> Looked at it again, and being able to get the total row count will work
> for me. Is this information already available, or does this still need
> to be implemented?
What would you expect from the "row count" requested for a
non-scrollable cursor? It cannot return the true count,
19.12.2021 16:04, Mark Rotteveel wrote:
Looked at it again, and being able to get the total row count will work
for me. Is this information already available, or does this still need
to be implemented?
Implemented but not yet committed. I will post a pull request tomorrow.
One last thing I
On 08-12-2021 10:13, Dmitry Yemanov wrote:
28.11.2021 14:45, Mark Rotteveel 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.
On 2021-12-08 10:13, Dmitry Yemanov wrote:
28.11.2021 14:45, Mark Rotteveel 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.
08.12.2021 13:49, Dimitry Sibiryakov wrote:
Storing of fetched rows is unavoidable indeed but prefetch?.. Is it
done in background or before returning of the first row to client even
in embedded mode?
The latter. But prefetch is done in small chunks, usually it does not hurt.
Dmitry
Dmitry Yemanov wrote 08.12.2021 10:54:
For scrollable cursors, rows are prefetched and cached by the engine and thus
the count can be easily returned. It has its cost, but generally it's
unavoidable anyway for scrollable cursors.
Storing of fetched rows is unavoidable indeed but prefetch?..
08.12.2021 12:37, Tony Whyman wrote:
It would also be very useful to get rowcount
returned for unidirectional cursors if that was readily possible. At
present, it is only possible to get an accurate count of the number of
rows in a cursor after you have fetched all of them.
It cannot be
On 08/12/2021 09:13, Dmitry Yemanov wrote:
3) "row count" makes it possible to know the position after
fetchLast() and everything else could be calculated locally by the
client library, thus making the server-supported "current position"
totally unnecessary.
Do I miss anything? Could we
28.11.2021 14:45, Mark Rotteveel 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
Mark Rotteveel wrote 01.12.2021 18:02:
You need to set the cursor name before you open it, IIRC.
Actually it doesn't matter. It is enough to set cursor name any time before
using of positional DML AFAIU.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
On 01-12-2021 16:06, Dmitry Yemanov wrote:
01.12.2021 16:07, Dimitry Sibiryakov wrote:
Also if IResultSet is returned from IAttachment::openCursor() there is
no (visible) IStatement at all.
And I see the same problem for setCursorName() which is available only
through IStatement. An
Dmitry Yemanov wrote 01.12.2021 16:06:
And I see the same problem for setCursorName() which is available only through
IStatement. An oversight?
IAttachment::openCursor() has a parameter for cursor name.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
01.12.2021 16:07, Dimitry Sibiryakov wrote:
Also if IResultSet is returned from IAttachment::openCursor() there
is no (visible) IStatement at all.
And I see the same problem for setCursorName() which is available only
through IStatement. An oversight?
Dmitry
Firebird-Devel mailing
Dmitry Yemanov wrote 01.12.2021 9:10:
Given that any DSQL statement cannot have multiple result sets, I doubt
IResultSet::getInfo() is really required, IStatement::getInfo() could be used
instead. Or if we go for consistency, IResultSet::getInfo() could be added, but
internally it calls
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.
Given that any DSQL statement cannot have multiple result sets, I doubt
IResultSet::getInfo() is really
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
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
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
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.
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.
26.11.2021 14:51, Tony Whyman wrote:
Just compiled the updated master branch and tested with IBX. All looks
good with the test suite returning the same set of results for bot
remote and local databases.
Many thanks for the good work.
And my thanks to you for testing ;-)
I've noticed that
Dimtry,
Just compiled the updated master branch and tested with IBX. All looks
good with the test suite returning the same set of results for bot
remote and local databases.
Many thanks for the good work.
I've noticed that the ODS is now 13.1 compared with 13.0 for Firebird
4.0.0. Is this
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. As long as the performance behaviour is
On 2021-10-27 09:55, Dmitry Yemanov wrote:
23.10.2021 17:13, Mark Rotteveel wrote:
If record buffering is hard, it could have been done **without** it.
Then it would have been the choice of the user whether it is worth the
performance implications or not.
So you consider acceptable that
23.10.2021 17:13, Mark Rotteveel wrote:
If record buffering is hard, it could have been done **without** it.
Then it would have been the choice of the user whether it is worth the
performance implications or not.
So you consider acceptable that forward-only usage of scrollable cursors
is
On 23-10-2021 15:14, Dimitry Sibiryakov wrote:
Mark Rotteveel wrote 23.10.2021 14:31:
I'm not sure why not.
Because of record buffering it is too hard for a feature with so
little usage.
I disagree, either it should have been implemented fully, or not at all.
If record buffering is
Thanks guys for responding. The only issue I have is that the release
notes don't seem to tell you that DSQL scrollable cursors are only
available for local databases.
On 23/10/2021 14:14, Dimitry Sibiryakov wrote:
Mark Rotteveel wrote 23.10.2021 14:31:
I'm not sure why not.
Because of
Mark Rotteveel wrote 23.10.2021 14:31:
I'm not sure why not.
Because of record buffering it is too hard for a feature with so little usage.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
On 23-10-2021 14:04, Tony Whyman wrote:
I have been testing out the scrollable cursors API and working with the
example employee database. What I am seeing is that scrollable cursors
only seem to work with local databases and not remote databases. Is this
true? There seems to be nothing in the
Tony Whyman wrote 23.10.2021 14:04:
Is this true?
Yes. This feature is not implemented in standard network plugin and so far
nobody created a custom one.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
52 matches
Mail list logo
