|Subject||Re: [IBDI] Re: Firebird 1|
> Not for me. Second time, you do the same select and discard rows 0 to 39and
> so on. For this to be coherent, you need either to keep open a snapshotthe
> transaction for every fetched web page (with a NEXT button, maybe) or to
> keep the original result set available all this time to be able to pick
> following chunk of 10 records. This is the caching that middleware does.Well that is quite a simple choice to make. If you need it to search the
> Otherwise, you want to recalculate again and again the same query and get
> different chunks of it, but consistency is not guarantee if the db changes
> in the meantime.
next items you must obviously introduce state in the form of a session or
something. Store the IDs of the records in an array in a Session variable
or something like that.
The case I am referring to is when you DO want to show the current database
state and not a snapshot of it. I think both LIMIT and introducing a state
both have their merits, and neither will solve BOTH problems.
Anyway, I think this point has been a bit over-laboured now, I only asked
about it to see if there were any plans for it, and to explain why
introducing a state was not suitable. I think this has now been