Share via

Caching Data

  • Article

When clients access your ASP page, there are basically two ways to provide them with the information they need:

  • Your ASP page can either obtain information from server resources, such as from data that has been persisted to a database, or
  • Your ASP page can obtain information from within the application.

Retrieving data from a resource outside the application will require more processing steps, and will therefore require more time than generating the data from within the application space.

If the data you are going to send to the browser has already been prepared by a previous request, your application will be able to retrieve that data faster if you store it in a cache. This form of caching is called output caching. Output caching is particularly suitable when you expect to return the same data in the same format for many different requests. For example, one common task for developing an input form is to gather persisted data as members of a drop-down list box. This is preferable to writing the entries directly into the HTML page, because updates to the persisted data will automatically be reflected in the form.

The following script is an example of output caching. In this example, the getSportsListBox function creates a list box from persisted data. The list box is added to the application space so that clients can access it more quickly than they could if they populated the list box on an individual basis. The example assumes that a Data Source Name (DSN) called "Sports" is defined on the server.

  <%@ LANGUAGE=JavaScript %><HTML><BODY>
<FORM METHOD=post>

What is your favorite sport? <%= getSportsListBox() %>
<P>

<INPUT TYPE=submit>
</FORM>
</BODY>
</HTML>

<%

function getSportsListBox()
{
  SportsListBox = Application("SportsListBox")
  If (SportsListBox != null) return SportsListBox;
  crlf = String.fromCharCode(13, 10)
  SportsListBox = "<select name=Sports>" + crlf;
  SQL = "SELECT SportName FROM Sports ORDER BY SportName";
  cnnSports = Server.CreateObject("ADODB.Connection");
  cnnSports.Open("Sports", "WebUser", "WebPassword");
  rstSports = cnnSports.Execute(SQL);
  fldSportName = rstSports("SportName");
  While (!rstSports.EOF)
{    SportsListBox = SportsListBox + "  <option>" +      fldSportName + "</option>" + crlf;    rstSports.MoveNext();  }
  SportsListBox = SportsListBox + "</select>"
  Application("SportsListBox") = SportsListBox
  return SportsListBox;
}
%>

In some circumstances, your application will receive many different requests for the same data, but you will need to change the presentation of that data for each request. In that case, you use input caching. With input caching you save the data, but not the presentation of it. You accomplish this by caching the data with a Dictionary object provided by VBScript, or with an ADO recordset.

The following example demonstrates caching data by adding a connectionless recordset to your application. ASP scripts within the application space can then access the recordset rather than retrieve the data from the database. The following two ASP scripts demonstrate this technique.

Excerpt from Global.asa:

  <OBJECT ID=rsCustomers PROGID="ADODB.Recordset" RUNAT="Server" SCOPE="Application">
</OBJECT><!--METADATA TYPE="TypeLib" FILE = "C:\Program Files\Common Files\system\ado\msado15.dll"
-->

<%  SQL = "SELECT CompanyName, City FROM Customers"  Cnn = "DSN=AdvWorks"  rsCustomers.CursorLocation = adUseClient  rsCustomers.Open SQL, Cnn, adOpenStatic, AdLockReadOnly  rsCustomers.ActiveConnection = Nothing
  Set myCustomers = Application("rsCustomers").Clone  Set CompanyName = myCustomers("CompanyName")  Set City        = myCustomers("City")
  Do Until myCustomers.EOF%><B><%= CompanyName %></B> is located in <B><%= City %></B>.<P>
<%
    myCustomers.MoveNext
  Loop
%>

The application's Global.asa file creates the recordset and adds it to the application space. The ASP script then populates the recordset and makes it connectionless by setting the ActiveConnection property to Nothing. The ASP script then clones this recordset and iterates through its values, which is much faster than accessing the database itself. This technique is appropriate only if you know that the data that will be used to populate the recordset is relatively stable.