Architecturally, this may introduce a different approach other than a page refresh to show the next n-rows.
AJAX, Flex or any event based solution could reduce how and when to get the next set of records. I remember in a previous .Net application that there existed a scheme to get the next set of data while you were viewing the current set, so caching was being handled prior to the next request. The caching in that example happened for the record set prior to current as well and the next records. This gives the illusion of performance, but you still see the data is a responsive way, which at the end of the day was all that matters illusion or not. Teddy R. Payne, ACCFD Google Talk - [email protected] On Mon, Feb 23, 2009 at 3:03 PM, Mischa Uppelschoten ext 10 < [email protected]> wrote: > : But if the query is run *every time* when you go to next page, inst it > : defeating the very purpose of pagination i.e. less load in performing > query > : to get 1000s of records at once. > > I think every situation where you may have 1000s of records being delivered > to CF is potentially suspect. IMHO that is more of a design flaw than a > pagination quest. > /m > ------------------------------------------------------------- To > unsubscribe from this list, manage your profile @ > http://www.acfug.org?fa=login.edituserform For more info, see > http://www.acfug.org/mailinglists Archive @ > http://www.mail-archive.com/discussion%40acfug.org/ List hosted by > http://www.fusionlink.com-------------------------------------------------------------
