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
: 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
Allen is right that you don't want to execute the entire query against the
database every time the display of the data subset changes. But there are two
ways you can go about that:
1. Execute the full query once, cache the results, and pull the page data
out of the cached results. This
Thanks Teddy, I appreciate your input. That was very helpful and it makes
lot of sense.
Assuming you choose 10 seconds for your threshold, If you have a template
> that runs 45 seconds three times a week versus a template that is 25 seconds
> that runs 100+ times a week. You may want to choose th
Ajas,
Slow running pages are subjective. You have to consider two aspects when
considering thresholds for slow running page logging.
What is slow to you as a developer?
What is slow to the business?
Typically, the developer will shoot low and the business will estimate
high. You have to find a
Ajas, if you're using SQL Server 2005 or Oracle, there are much better
solutions...the problem with what you showed in the first link is you (the
server) is always retrieving ALL rows from the given table and pushing those
across the pipe from your SQL server to your web server. There are two t
