"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:37484737-5A3A-4F59-BAD0-2768C77D5316@news.elevatesoft.com:

> Think bookmarks, findkeys, locates, etc. which move the record pointer
> arbitrarily to a given position in the dataset.  Calculating the
> logical position of the record pointer at such a juncture can be very
> expensive if the record pointer is in the middle of the dataset and
> the dataset contains a lot of rows.

Think Greyhound bus full of people stops at roadside café:

SELECT * FROM GreyhoundBus
WHERE IWantAPee = TRUE
OR IWantABurger = TRUE
ORDER BY Age DESC, Sex, SeatNumber

all these people get out of the bus, and are sent to Café. As they pass
through the door they get given a ticket with a sequential number on it
(bearing no relation to their seat number), which they have to return to
the bus-driver when they come back so (s)he can know if everyone has
returned.

I don't see why the numbering-as-the-record-goes-out-the-door scenario is
so costly, as it happens after all the searching and gathering is over.

The first out the door is 76, female, from seat number H3, the next is
73, male, from seat M2, but I don't need to refer to that data to give
her ticket 1 and him ticket 2.

But don't lose any sleep over re-explaining - I'll take your word for it,
and use the quite satisfactory workarounds instead, given the advantages
of not having statistics.

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.24 Build 1)

Chris


That would probably be ok for canned datasets but where they are live datasets where are you going to store the info?

Roy Lambert

Chris,

<< all these people get out of the bus, and are sent to Café. As they pass
through the door they get given a ticket with a sequential number on it
(bearing no relation to their seat number), which they have to return to the
bus-driver when they come back so (s)he can know if everyone has
returned.

I don't see why the numbering-as-the-record-goes-out-the-door scenario is
so costly, as it happens after all the searching and gathering is over. >>

Roy is correct - you're thinking in terms of static data when in most cases
the data is anything but static.  The row buffers that you see in a TDBGrid,
TDBEdit etc. are all constantly retrieved and refreshed from the actual
dynamic table as navigation, etc. takes place.  The sequential positions of
the rows are also constantly changing, thus there is no way to really
"store" the position information anywhere without being forced to constantly
recalculate them, which puts us back in the "costly" camp.

--
Tim Young
Elevate Software
www.elevatesoft.com

> That would probably be ok for canned datasets but where they are live
> datasets where are you going to store the info?

SQL 2005 has a new rownumber feature that does this; it's not stored in the
table, but just returned in the query.

Jerry,

<< SQL 2005 has a new rownumber feature that does this; it's not stored in
the table, but just returned in the query. >>

I understand, but it's still not very practical with live result sets.
Static result sets are fine, but live result sets are a problem.

--
Tim Young
Elevate Software
www.elevatesoft.com

> I understand, but it's still not very practical with live result sets.
> Static result sets are fine, but live result sets are a problem.

You would be correct! I missed the "live" part, sorry