On 2001.06.01 12:27:57 -0400 Peter Morris wrote:
> >The server should
> > not be required to keep hordes of caches around just to spit out small
> > slices of datasets efficiently. Nor should it be made to re-execute
> queries
> > over and over again just to increment through data.
> It will be required to do this anyway if a website asks for records X-Y
> and
> then Y-Z on the next run.
>
> > What should be happening is using bookmarks derived from meaningful
> data
> in
> > your table that allows the server to quickly pull records from the next
> > segment and then it just brings back rows until you don't want any
> more.
>
> Sounds interesting. Say I have a table which has only
> ID INTEGER,
> FIRSTNAME VARCHAR(32),
> LASTNAME VARCHAR(32),
> DOB DATE
>
> If I decide to select * from MyTable order by LastName, FirstName
> I display the first 10 records, what do you suggest the query should be
> to
> select from that point onwards ? (Considering there may be many many
> people
> with the same first/lastname and DOB).

I think you have come up with a conclusive reason to use the app server
approach of getting the complete list into a session and parcelling out
numbered rows from it.

Why? there is no reason to expect the db to return the rows in the same
order on repeated query executions if all the columns in the order by set
are not sufficient to distinguish rows.

>
> > When you want more records you somehow say, this is the new starting
> point
> Somehow ? How ? This is the whole point. If you can show me a way to
> do
> this with a single select I would be very happy.
>
> Although I must say 1 more thing. If your select requires me to pass
> firstname, lastname, dob from the last record I displayed, this means I
> would have to store this in a <form> and pass it back to the server.

Or in a session on the app server

> What
> happens when there are 10 or more fields ? Especially if I am using
> METHOD=GET ? Very messy !
>
> Pete
> ===
> http://www.HowToDoThings.com
>
david jencks