Paging and caching large record sets Support

Today we look at viewing large record sets, and how to optimise this process both for the person doing the viewing and for the server processing the page. To handle the former, we'll use a technique known as paging, and for the latter, caching. This caching is not the client side browser caching we've all come to know and hate; this caching is done entirely on the server.

 

The code supplied is half the length of the Dreamweaver-generated code, and is hugely beneficial if you have a site where users look through large lists of data without amending it.

Advertisement DMXzone Paginator ASP

Add the coolest page navigation to your site and make browsing through large lists of items or tables easy and quick. Choose from 22 different styles, used by many sites such as Digg, Yahoo, Flickr and much more, to fit perfectly with your design and display the total number of items.

All paging styles are fully CSS based, so you can always fine tune the colors and borders to your site design.

 

 

1. Workspace

First off, we define some formatting functions (for dates and currencies), and define all of the variables we'll need. Notably, we set up currentPage and orderIndex with their initial values (both 0), and we set up pageSize with the number of items we want to display per page.

    Note - the formatting functions here aren't intended for production use, I include them merely to illustrate that these can exist, and can provide any formatting function, however simple or complex.

    function FormatShortDate ( dateObject ) {
     return dateObject.getDate() + "·" +
     ( dateObject.getMonth() ) +
     "·" + dateObject.getFullYear();
    }
    function FormatCurrency ( value ) {
     return "R" + value + ".00";
    }
    var orders, order;
    var pageSize = 2, currentPage = 0, paging, nextPage, totalPages;
    var orderIndex = 0, endPoint, recordCount;

2. Determine where to get the data from

Next up, we need to determine in some way whether or not to retrieve the data from the database or from the cached copy in Session. Determining this is quite easy: if the cache doesn't exist, create it. Additionally, the cache could exist, but the data it contains could be out-of-date. To determine this, we check an Application variable (which is accessible from all sessions in the application) named OrdersChanged for the value 'changed' to see if some other process has modified this data. Obviously, you would have to set this variable to 'changed' in any script you write that modifies this data in the database.

    if ( Session( "Orders" ) != null &&
     Application( "OrdersChanged" ) != "changed" ) {

3a. Retrieve cached data

If we find that the data in the cache is still good, we create a local (to the script) reference to it. Additionally, we check to see if we've received page via the query-string, and if so, we parse it as a number to our local currentPage variable. Doing the page check inside this branch, instead of as a part of the if statement above, allows users coming back to the page from another page to make use of the cached data.

     orders = Session( "Orders" );
     if ( String( Request( "page" ) ) != "undefined" ) {
     currentPage = parseInt( Request( "page" ) );
     }