Unlike Session variables, there is only one instance of each Application variable. This means that storing data in an Application variable – including memory-consuming data such as long strings or arrays – doesn’t severily impact on system performance (unless you store strings with thousands and thousands of characters, of course).
The ideal candidates for being stored in an Application variable are read-only data, for example the ConnectionString property that you later reuse in any ASP page that accesses the database. Typically, you set this variable in the Application_OnStart event procedure in Global.Asa.
Connection strings aren’t the only data that can and should be stored in Application variables: any static data is a potential choice. For example, you might read the names of US states or of world countries from a database table and store them into an array, and then store the array into an Application variable. Or you could store an array with the names of product categories – which can be easily considered as static data.
Better yet, if the stored information is bound to be displayed as HTML text, you might prepare the HTML text in advance, and store it in an Application variable. A good example of this technique is the HTML text for a combo control that stores all the product categories:
' this code creates a combo control that contains ' the list of product categories, and stores the resulting' HTML text into the Application("CategoriesHTML") variableDim rs, html, indexSet rs = Server.CreateObject("ADODB.Recordset")' the connection string is already in an Application variablers.Open "SELECT cat_name FROM Categories", Application("ConnectionString")' start creating the Combo controlhtml = ""rs.Close' store in the Application variableApplication.LockApplication("CategoriesHTML") = htmlApplication.Unlock
You can store the above code in a separate file, that you can include in Global.asa (after the point where you define the Application(“ConnectionString”) variable, though.
The flexibility of this approach becomes evident if the data isn’t really static, and can sometimes vary during the life of the application. For example, when a new product category is added to the database, you just have to include the same file – immediately after the point where the database has been updated – so that the data in the Application variable is always in sync with the data in the database table.