Audit history

In SQL Server databases, changes to the data in iBase entity and link records can be recorded.

Changes are recorded following these iBase operations:

  • Entering and editing records

  • Deleting records (including soft-deleted records)

  • Batch editing

  • Merging entities

  • Assigning icons

  • Importing data, including bulk import

  • Editing code lists

Audit History is independent of the audit level of the database and, if used, the following actions become available at all audit levels in Audit Viewer:

  • Record Added

  • Record Modified

  • Record Deleted (not including soft-deleted records)

  • Code List Modified

  • Bulk Import

However, in a database with audit level 5, you can also find out who viewed specific records.

Note: Audit History is automatically turned on if you initialize a database for alerting and you cannot turn it off when alerting is active. The audit history provides the details that enable users to understand the edits and views that raised the alerts. The same details are displayed regardless of the audit level of the database. A user who is denied access to the Audit History cannot view the details.

Audited field types

Aside from data associated with calculated fields (that is not directly stored, but depend on values held in other fields) all field types can be audited. In the audit log, all data is converted to text apart from Document and Picture fields which are stored in their original format. You can view this historical data in Audit Viewer or in iBase itself when showing a record or link, unless permission to do so is denied.

What is recorded

The following are recorded when a record is updated in iBase:

  • Original value

  • iBase user who made a change

  • Date and time the change was made

  • Machine name of the editing user

  • OS user name (name of the Windows user)

  • Reason for the change

  • SCC -- needed to ensure that the user only sees the data they should if SCC values are altered during records history

  • Location of user -- from iBase user location

  • Reason for the update (optional)

  • Whether the update was made using an i2 product

  • Data in the extra field (if this feature is used)

The following is recorded if an iBase record is updated directly in SQL Server:

  • The name of the account used to connect to SQL Server

If a single record was changed, the audit log records a Record Modified action and the record ID is displayed in Audit Viewer. This is not possible for a bulk import when the audit log records a bulk import action.

Note: Changes to code lists are also audited, that is old and new values, descriptions and parent pick lists.

Setting up audit history

To enable and set up audit history, in the iBase Designer Database Properties, turn on Audit History. An Audit History action is added to the audit log to record when, and who, enabled this feature.

You can require users who modify records in iBase to enter the reason for the edit before they can save their changes:

  • In iBase Designer, select System Commands Access Control >Reason For Action and turn on or off Data Auditing.

Note: You might need to run the Tools Update Command Groups command first.

By default all users are able to view the audit history. To deny users access, edit the appropriate user group:

  • In iBase Designer in the System Commands Access Control dialog, display the Access Denied page and turn on or off the View History checkbox.

You can also configure audit history to disable the guest account and replace it with an existing SQL Server login for audit history logging. For further details, see Changing account used to log audit history.

Maintaining auditing stored procedures

When a user logs into a database with Audit History turned on, checks are made on the SQL Server database and, if any problem is detected with auditing, the user is denied access to the database. To fix the problem, reopen the database in iBase Designer.