Nigel Weeks wrote:

>Hopefully I've got this right...
>When the following query is performed on a table with 500,000 rows:
>
>select first 50 skip 50 * from table where condition = value;
>
>The entire recordset is created based on joins, where conditions, etc.
>Then 50 records are skipped, 50 records are returned, and the remaining
>memory is deallocated, ready for the next query.
>
>How hard would it be to add an internal conduit to the external interface to
>give some information(namely, number of records) about the entire recordset,
>before the skipping and first operations occured?
>
>
>

It would be both unpleasant to implement, very slow, and couldn't be
done with complete accuracy. There is no way to computer the number of
records to be fetched without materializing each record. Then there are
two ways to go. One is to throw the records away and rematerialize
them. The other is to try and save the materialized records. The
latter if frought with peril since the host program is free to update a
record, and the update would need to be tracked. Regardless of how that
problem is handled, there is also the case where a record is modified by
a different request in the same transaction, taking it out of the record
set. This would lead to the condition where the number of records
reported and the number actually fetch differ. And then there's the
problem of a new record inserted that should belong to the record set.
Depending on where it ended up in the data pages maybe it would be
found, maybe not.



--

Jim Starkey
Netfrastructure, Inc.
978 526-1376