ALP Application.StaticObjects collection

StaticObjects collection contains objects created using <OBJECT RUNAT=SERVER ...> HTML tag in the global.asa file. This collection is most often used in a transparent way and is used to extend the ASP object model with additional pre-initialized objects. To learn how to do this in details see global.asa reference.


  1. Set variable = Application.StaticObject(key_name)

  2. Set variable = Application(key_name)

  3. And the favorite way to access the collection:
    Set variable = key_name
    or just:
    ... key_name.some_member ...


key_name - string that is used as label for the object referred. It corresponds to the ID attribute of the <OBJECT RUNAT=SERVER ...> tag used to create the object.

variable - a variable receiving reference to the object from the collection

If key_name does not exist in the collection Empty is returned.

Second syntax is not recommended because it relies on the fact that there is no value with the same key_name in the Contents collection. I.e. the Application object when invoked in this way: Application("key_name") will attempt to find the passed key name in the both Contents and StaticObjects collections and will return the first found. While in small applications this may help save some code it is a bad practice in production applications where it may lead you to mistakes as the application grows.

The third syntax is the most frequently used way to access the objects in this collection. As the main purpose of the StaticObejcts collection is to extend the ASP object model ALP adds implicitly all the objects from the StaticObjects collection as pre-defined object variables to each ASP page. Thus the ASP pages in the ALP application that defines these objects in its global.asa file may refer to them as like to the built-in ASP objects (Request, Response, etc.). This allows the developer prepare specific environment for the application that will minimize the code needed for many tasks and will adapt the ASP object model to the application needs.


In gloal.asa:
<OBJECT RUNAT=SERVER ID="db" PROGID="newObjects.sqlite.dbutf8" SCOPE="Application"></OBJECT>

In an ASP page from the same application
    Set r = db.Execute("SELECT * FROM MyTable")
    For I = 1 To r.Count
        <%= r(I)("Name") %>, Age: <%= r(I)("Age") %><BR>

Assuming that the database is opened in the Application_OnStart in global.asa the regular ASP pages do not need to do anything else than using the already prepared database object and do the actual work for which they are designed. 


The StaticObjects collection in Application and Session objects is a very powerful technique that allows the developers create their own object model for their applications. The objects kept in Application.StaticObjects have application life-time. This allows the developer create objects for caching, pre-initialized database access, certain utility objects and so on. This is especially useful with:

threads (see COMScriptThread) - the thread object(s) can be created and initialized once and tasks can be send to it wherever needed from within the applicaiton.

databases (see SQLite COM) - once opened in global.asa they can be used with ease throughout the application minimizing the efforts.

Utility objects such as StringUtilities, VarDictionary and many others to provide pre-configured tools or custom cache/data storages for the application.

Shared files/storages - See SFMain, SFStream, SFStorage. By opening them in the global.asa and using them through a single application wide variable the application is ensured that any access to them is serialized and no data corruption will occur.

Applies to: Application object

See also: Session object , Application.Contents , global.asa

newObjects Copyright 2001-2006 newObjects [ ]