--- In IBDI@y..., "Peter Morris" <pmorris@m...> wrote:

> ... my problem is that the result will not be

ordered by

> any 1 specific field every time someone requests the list (may be

name, or a

> date etc), but once the query is decided it will remain the same for

the

> whole list so the results will always be in the same order.
>
> I could request the whole result set, and then use next until I

reach the

> last record previously displayed, but this way I would have to

request a lot

> of data just to throw it away.
>
> Pete

Hi, Pete. Firstly, I beg your pardon for "it's Peter" in previous
post, we Russians often make this mistake when hasty because "he is"
and "it is" is the same single word in our language and unfortunately
it sounds like "it".
Let's remember how IB access data: optimizer tries to implement
indexes on join and where conditions, builds access bitmap and
searches data using it. There is not point to implement order of
fetched row in this schema. So Limit can be implemented via somewhat
middleware only. It can be (all are ineffective for different
reasons):
1. Client-cashed stable result and filtering/sorting on internalcalc
columns, like in ClientDataSets.
2. Client-side filtering by RecNo on every select execution.
3. Those stored procedures.
4. My proposition in previous post - some "engine-side middleware" -
Limit in statement sets some flag and this flag is used when FETCHING
AFTER access bitmap is built. Actually, effectiveness it the same as
for SP but you are not forced to code separated SP for every
statement. What about some people can start to use it where it is not
needed - well, some people tries to use nested selects instead joins
just now, it is their own problem. May I ask FB developers about how
complex is to add this feature?

Best regards.