The event context (_Event-context field of the _aud-audit-data table) is an indexed field and the primary mechanism for locating what audit data exists for a specific event ID, such as what changes have occurred for the specific customer number. It is extremely important, therefore, that the event context be structured in a useful and consistent manner according to the type of event. If the structure or format of the event context varies for a specific event, it would be difficult to locate records over time—especially since it is not possible to update audit event data to correct the format at a later time. For security reasons, audit data can never be updated, under any circumstances.

Each audit event must have a well-defined and published event context format to facilitate efficient querying. For application events, this is left to the developer to define, and care should be taken to record this consistently. For internal and database events, each event has a predefined structure and format.

For audit events, where no database record operation is involved, such as for internal database PROUTIL utility events, the format of the _Event-context field is as follows:

All database event record operations use the following format:

The id-fld-val and id-fld-val-n refer to the identifying field values as defined in the table policy records, defaulting to a tables primary key fields.

Note that identifying fields can be used only if they belong to the table being audited; it is not possible to specify a field from some related table to use in place of the foreign key value. This presents limitations in the case where the foreign key is a meaningless object ID, and a GUID and more meaningful data exist only in the related table that the GUID points at. In such cases, the report must have an internal knowledge of how to join to the related table at run time, as well as have access to the database the related data resides in, which might be an issue for historical or deleted data.

An option to work around this is to force audit data to be created for the related table with full detail being recorded of the required field values, and then to retrieve this information from the audit data tables as well, removing the dependency on the original database and schema.

The event context field is a character field, as described, and is limited to 200 characters (because it is indexed). This could also present some limitations for tables with many or large identifying field values, as part of this 200 is taken up by the owner and table name as well as the delimiters. For reporting or querying, this could result in truncated values; give careful consideration as to the identifying field values used.

Note that locating specific audit data for a record requires knowledge of the structure of the event context, and, therefore for database events, knowledge of the identifying fields used—as it is only the value that is recorded—not the field name. The field values will be stored in American format for consistency, so also consider this when constructing queries to locate specific audit data based on the audit context.

It is possible to have multiple active audit policies with potentially conflicting sets of auditing fields for the same table policy. In cases where this occurs, the aggregation of all the fields marked as identifying fields across all the active policies will be used. If multiple fields have conflicting ordinal positions, the order will be unpredictable.

The implication of this is that the format of the context will be unpredictable and different for data in the same table, depending on the active policies. This could get very confusing and make it almost impossible to query against specific audit data for specific records. Avoid this situation at all costs. Unfortunately, it is difficult to prevent; but Audit Policy Maintenance will at least provide a report that highlights the issue. This report should be run to identify conflicts before using the policy. For more information, see the Audit Policy Maintenance Help.