AX1063

Auditing changes to table data

Axiom Software can track the specific data changes made to each record in a particular table. This is a more granular level of auditing than what is available in the activity-based audit log, which tracks when actions are performed on a table.

Enabling auditing for a table

The table classification impacts whether auditing is enabled by default and whether it can be configured:

  • Data: Auditing is enabled by default. It can be disabled if it is not needed.

  • Reference: Auditing is enabled by default. It can be disabled if it is not needed. This includes picklist tables and KPI tables.

  • Document Reference: Auditing is enabled by default and cannot be disabled. However, if the in-memory table feature has been enabled for document reference tables, then the in-memory tables are not audited.

NOTE: If a table uses the Large Table index scheme, auditing cannot be enabled for that table.

If auditing status can be configured for a table, then it can be changed by modifying the Auditing setting in the table properties. If enabled, then the table has a corresponding audit table in the audit database. The audit table name is AU_TableName.

Generally speaking, auditing should only be enabled for a table if it is necessary to track the granular data changes to that table. Table data auditing can impact performance for import utilities, if the import involves large amounts of updated or deleted data for the destination table. Table auditing typically does not significantly impact the performance of other data saves within Axiom (such as using Save Type 1 or Open Table in Spreadsheet), although there are a few exceptions (such as saving extremely large amounts of data using File Processing with Save at End).

How table auditing works

If auditing is enabled for a table, then the corresponding audit table tracks when a record in the source table is updated or deleted. It does not track when new records are inserted. The audit table also does not track structure changes to the table, or other activities such as when a table was queried—these types of activities are tracked in the main audit log (viewable using the Axiom Audit Manager).

For example, if a save-to-database is performed and an existing record is updated in a table, this will be logged as follows:

  • The Axiom Audit Manager logs that the save-to-database occurred, as well as details such as the user who executed the save and what table was affected. This level of auditing is always available and cannot be disabled, though differing methods of save-to-database may produce different levels of detail.

  • If auditing is enabled at the table level, then the specific data change is logged in the corresponding audit table. This data change can then be viewed in the Axiom Audit Manager, or by querying the audit table directly (such as by using an Axiom query in a report).

    However, if auditing is not enabled at the table level, then the specific data change is not logged and cannot be viewed or reported on. You will only know that a save-to-database occurred.

The available audit history at any particular time depends on how your System Data Purge Scheduler job is configured. For more information, see Purging audit data.