OpenEdge records application context information in one place and then references that context information from many individual audit records. This approach is much more efficient in terms of I/O, CPU, and disk space resources, but requires additional work when creating reports.

When OpenEdge creates an auditing record, it automatically generates and inserts as the primary index a UUID value that is unique across time and space. The ID values are stored as compressed, character-encoded, Base64 values. The client session, application context, and audit event group records all have one of these ID index fields.

When one of the database clients generates one of these auditing context events, it passes it to each of the connected databases. If the database connection is not audit-enabled, the context event is ignored. Each audit-enabled database connection will record the event according to the events configuration in the databases audit policy. During this process, the primary index ID remains the same regardless of which database the event is recorded into. Even though each databases event record might have a slightly different time stamp, the event record is essentially duplicated. During archival merging operations, these duplicates can be removed without harming the integrity of the auditing data.

Within the auditing record are three indexed, foreign key, character fields that are used to hold the ID index values of client session, application context, and audit event group records. A fourth indexed character field holds the clients database transaction ID.

The following figure shows the relationship among the various auditing records.

Each clients database connection has storage for each of the four auditing context IDs. When the scope of a client session, application context, audit event group, or database transaction context begins, its ID is recorded in each audit-enabled database connection within the client. When the scope of a context ends, the contexts ID is cleared from each audit-enabled database connection so that it is no longer recorded in audit records.

When an audit-enabled database connection generates and writes any auditing record, it will copy the context IDs from the connections storage into the record. This recording of the auditing context ID occurs regardless of whether or not the context event is physically recorded in the database.