Audit - General remarks

The commands that cause a table transaction to be audited, are only the commands that affect the table data, that is, Insert, Update, and Delete commands.

Several table level commands that affect all rows in a table are also audited, such as Create Table, Drop Table, and Clear Table.

The audit configuration uses a positive approach. That means that you can only define the tables and fields that must be audited. You cannot define the tables and fields that must not be audited. To compensate for this feature, you can load lists of all packages, modules, tables or fields through the appropriate menu of the sessions concerned.

You can use tables and fields in various profiles with conflicting settings. To determine which setting takes precedence over the conflicting setting, these rules apply:

A higher level takes precedence over a lower level. For example, you define in profile A that all tables in a module must be audited. In profile B you define that only one table in this module must be audited. The result is that when you convert these profiles to run time, that all modules in the package concerned are audited.
The setting Always takes precedence over Changed. For example, profile A defines that a field must only be audited, when the profile is changed. Profile B defines that this field must always be audited. Then the field is always audited.