Question : Using SQL for Gridview Paging vs Caching

I came across an article which uses a stored procedure to return a specific result set for paging in a GridView (see code)

Instead of returning 10,000 rows of data, the stored proc will return only 20 of 10,000 rows (which you then bind to the GridView) assuming your GridView is set up to display only 20 rows per page.

I'm curious what advantages in efficiency this has over caching all 10,000 rows? I read that the built-in GridView paging becomes inefficent when dealing with large result sets. Would it be ideal to use SQL for paging rather than using caching and assigning tens of thousands of rows to the GridView when you only indend on displaying 20. Is this true?

Code Snippet:

         
           
             1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:

           
           
             CREATE PROCEDURE [usp_GetProducts] 
@startRowIndex int,
@maximumRows int, 
@totalRows int OUTPUT

AS

DECLARE @first_id int, @startRow int

SET @startRowIndex =  (@startRowIndex - 1)  * @maximumRows

IF @startRowIndex = 0 
SET @startRowIndex = 1

SET ROWCOUNT @startRowIndex

SELECT @first_id = ProductID FROM Products ORDER BY ProductID

PRINT @first_id

SET ROWCOUNT @maximumRows

SELECT ProductID, ProductName FROM Products WHERE 
ProductID >= @first_id 
ORDER BY ProductID
 
SET ROWCOUNT 0

-- GEt the total rows 

SELECT @totalRows = COUNT(ProductID) FROM Products
GO

           
         

Open in New Window

Select All

Question : Using SQL for Gridview Paging vs Caching

Answer : Using SQL for Gridview Paging vs Caching

just need to call Button1.PerformClick(me, nothing)