asp.net 2.0 customizing paging on SQL Server 2005

Source: http://aspnet.4guysfromrolla.com/demos/printPage.aspx?path=/articles/031506-1.aspx

Introduced

Pages are commonly used to display data in web development. Compared to the whole page to display a report or a data table data to the user, developers often use the paging display, each page shows only part of the data, with page control. In Aspv.net 1.X, the DataGrid control makes the page-flipping display simple-just set the property allowpaging to "true" and add a few lines of code to the PageIndexChanged event to achieve it! The control gridview in asp.net 2.0 simplifies the event by simply selecting "Allow paging" in the GridView Smart Panel, without a single line of code to implement it.

Of course, nothing in life can be done easily. You need to weigh the performance of the paging scheme (or the implementation of a few lines of code in a DataGrid) that can be implemented by selecting a check box. If you do not select pagination, the DataGrid and GridView use the default paging to simply display all the data to a single page from beginning to end. When the amount of data is hours, several 1100 or similar, the efficiency performance is not too obvious. However, if you imagine this by using the default paging method to display tens of millions and even hundreds of thousands of of books, it is not OK.

The way to replace the default paging is to customize pagination, and the job you have to do is to use code to judge and get the right paging data out, which may be a matter of membership, but it's definitely worth the effort to cope with such a huge amount of data. I discussed how to implement custom paging in asp.net 1.X in the asp.net web Data Control rapid development article, and we look at how ASP.net 2.0 uses the new features of SQL Server 2005 to Row_number () to implement custom paging. (For more information on the new features of SQL Server, see Using Microsoft SQL Server 2005 to return column values.) )

Read on to learn more!

Default paging vs. custom paging

In ASP.net 2.0, the GridView (or DataGrid in ASP.net 1.X) provides two paging models: default paging and custom paging. The two models provide a compromise between performance and ease of use. The SqlDataSource control uses the default paging (although you can use it in custom paging); ObjectDataSource defaults to using the default paging model, but there is a simple configuration that lets it use custom paging. Keep in mind that the GridView is only displaying data; it is the GridView data source control, which is responsible for retrieving data from the database.

With the default paging, all data is obtained from the GridView data source control each time a new page is opened and displayed. Once all the data is returned, the GridView displays all of the data on the page, so the user sees a page showing so much data. The key to understand here is that whenever a user accesses the first page or turns to another page, all the data is reloaded.

For example, if you work for an E-commerce company, you want to have users paging through the 150 of products that your company sells. Also, you want to display only 10 data per page. Now, when a user accesses a Web page, all 150 data is returned by the data source space. But the GridView only displays the first 10 data (product 1 to product 10). Again, when the user looks at the second page of data, this raises a postback event, and at this point the GridView gets all 150 records from the data source control, but only the second 10 (product 11 to product 20) is displayed.

Caching and SqlDataSource

Sqldatacourse allows the dataset to cache data after a simple setup of the property enablecaching. For a cached dataset, there is no need to access the database when paging, from the beginning to the end of the paging in memory. However, the same problem occurs when the page is initialized-all data must be loaded into the cached dataset. Also, you have to worry about outdated data (although you're using SQL cache dependencies, it doesn't make sense here). In my less-than-scientific test, I found that cached data and custom paging are twice times worse ... Although, you see the way caching approaches are not cached. (But it always doesn't exceed custom paging!) ） For more data set caching for SqlDataSource, see Caching Data using SqlDataSource.