(wa********@yahoo.com) writes:
If you were doing paging of results on a web page and were interested
in grabbing say records 10-20 of a result set. But also wanted to know
the total # of records in the result set (so you could know the total #
of pages in the set).
Would it be better to query the DB table 2X. Once for Count(*). And
again for the records for the current page?
Or better to create a temp table, select the records into it, and then
get count(*) and the page results from the temp table?
I saw an example in a book that made a temp table to do this and to me
it seemed like it would be slower. I don't get the reason for a temp
table. Anyone have any ideas?
A temp table could be slower because of recompilations.
An alternative is to use a permanent table, that would have some session
key and an IDENTITY column (in SQL 2000). When the user makes his first
search, you get all data into that table. Then as he pages on, you retrieve
the rows from this table. This means you don't have to redo the query for
subsequent pages, but can get it from the table. This is likely to give
better performance, and another advantage: a fixed result. If the result
can change as the user browse, he may miss a row that initially was row
101, but now is row 100.
Finally, don't design pages where the user only can get 10 rows at a
time. I hate those. Give me at least 100 at a time.
--
Erland Sommarskog, SQL Server MVP,
es****@sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx