Overview
The Advanced Audit Logging feature provides comprehensive tracking and logging of specific table data changes within a database. This feature ensures all modifications to critical data are recorded in dedicated audit tables, enabling robust monitoring, security, and compliance.
Note - this feature needs to be activated by Equus. Please speak with your Equus representative if you are interested in using it.
Tracking
The feature monitors Insert, Update, and Delete operations on specified tables.
It will identify the:
Who/what (user or process) that triggered the change
How the user/process changed the data
What data has changed
Comprehensive information around the data change will be captured, taking a snapshot of the record after insert and update, or before being deleted. Information about the changes are also captured, including the old and new values for each modified column, on a per-table audit view.
Supported tables are listed here.
Audit Tables
Each table that is being audited will have a corresponding audit table. Audit Table information can be freely reported on using a standard User Report. Note that each audit table:
Has the same set of fields plus additional audit columns (as described below)
Will be named AAL_TABLENAME (eg: Assignment will have AAL_ASSIGNMENT)
Will include a view comparing old and new values per change on each record
Additional Audit Columns for Audit Tables:
Audit Event User - The identity of the user/process responsible for changes
Audit Event Description - The identity of the user who made the change
Audit Event Date - Date of the event
Audit Event Type - The type of operation (Insert, Update, Delete)
Audit Id - Unique identifier per change (Note a change may result in several audit records)
Additional Audit Columns for Audit Table Views (Per Column):
AET_(Audit Event Type)COLUMNNAME - The type of operation (Insert, Update, Delete, Null).
NV_(New Value)COLUMNNAME - The value of the column after the change (Insert or Update or Null), or before the DELETE.
OV_(Old Value)COLUMNNAME - The value of the column before the change (Insert or Update or Null), or after the DELETE.
Each view will be the same as the Audit Table with additional columns as described above. Each view will be named VWEQ_AUDITTABLENAME (eg: Assignment will have VWEQ_AAL_ASSIGNMENT)
Things to Note
Classifications have a specific column since they hold 2 values (Code and Display value). On each column that supports a classification, there will be an additional COLUMNNAME_DV (Display Value) whereas COLUMNNAME will display the code of this field
For T-Calcs, a specific AET_COLUMNNAME value will be CALC, meaning that the expression that calculated that field is being calculated
Private Field and Encrypted fields will respect the same rules as in the audited tables
Encrypted fields will be copied and such and cannot be un-encrypted on the log table - just on the audited table
Private fields will respect the Field Access Rights on the parent table - if the user can see the field in the audited table, they will also be available on the log tables.
To comply with GDPR (Right to be forgotten) any linked log record related to deleted assignments is also purged when an assignment delete batch is executed. This means that any existing logged information linked to an assignment that is being deleted through the batch process will be purged when the assignment record is also deleted.
Currently, Custom Field Tables do not appear in Log table results like standard tables. To audit the ASSIGNMENT_CF table, you should create a report type directly into the AAL_ASSIGNMENT_CF table instead of using the AAL_ASSIGNENT table.
In addition the name of the columns for the AAL_TABLENAME_CF will be the physical table column names (eg CF_DATA_001, CF_TEXT001,…) instead of the 'Business names' those columns have in the standard tables.
Any AAL_TABLENAME cannot be targeted by any import process
AET field captions that you see in user reports in the reporting views start with the word “Event – “ followed by the name of the field