Controlling what is audited

iBase starts auditing at the lowest possible level of detail when you create a database. You cannot stop this level of auditing but you can choose to start at a higher level, and to modify all auditing options for existing databases. The audit level applies to all users equally, and only to the database in which you specify it.

Each of the available auditing options and the circumstances when you might want to use them are described in the following information.

Note: Independently of setting the audit level, you can configure the database to log commands that are run by users, case control, and audit history. For more information, see:

Audit levels 1 - 5

Level 1 records the least detail and level 5 records the most detail. The level of auditing is cumulative, each level records the information for all lower numbered levels. For example, level 3 records queries and all information specified by levels 1 and 2.

The table details how to set audit level descriptions.
Level Description
1 Logs each time that a user logs in, a database is opened or closed, or when an email alert is sent.
Note: If the database is configured to audit the use of commands, or to request a reason for use of a command, those commands, and reasons appear at this level. If your SQL Server database is set up for Audit History, extra logging occurs at all levels. Also, if an SQL Server database is case-controlled, the log always records when cases are added, modified, deleted, renamed, closed, or reopened.
2 Also logs when entity types, link types, and fields are added, changed, or deleted. In other words, this level logs a change of database design.
3 Also logs each time that a query is run on the database. The query can be direct, for example by using Find, Browse, Query, or Search 360; or indirect, for example by using a browse definition based on a query. Search 360 search criteria are audited at level 3 and upwards.
Note: The log does not include work on sets or how the data was retrieved.
4 Also logs when entity and link records are added, changed, or deleted. In other words, this level logs a change of database data content. The log includes when records are soft-deleted, or purged and when a conflict is detected, or restored, or solved.
Note: The log does not include individual records that are affected by a Bulk Import, only the start and end of the import is recorded.
5 Also logs when entity and link records are accessed or viewed, without change to the data. This logging produces large volumes of audit data and for this reason, is available only for SQL Server databases.
Note: The log does not include individual records that are affected by a Bulk Import, only the start and end of the import is recorded.
Attention: Because XML exports can be used to export large amounts of data (potentially all the records in a database), XML exports are not audited.

More about audit level 5

Audit level 5 produces high volumes of audit data. For this reason, it is available only with iBase SQL Server databases. Use this option only when strictly required.

As a way of controlling the volume of audit data, you can set Number of records to be displayed before auto-pausing to a low number. When the audit level is 5, this option pauses the listing of records, returned by a query or browse, at the specified number.

The useful consequence for auditing is that the audit log records only the number of records that the user views. For example, if the user cancels after a pause that shows 50 records, only those first 50 records are shown in the audit log. If the user continues to list the other records, those records are audited as normal.

Audit level 5 can be used with Reason for Action entries. See System Commands Access Control Groups for details.

Audit history

In SQL Server database, changes to the data in entity and link records, and code lists, can be recorded if the Audit History is turned on. For audit levels 1 - 4, changes to the data are recorded and additionally, at audit level 5 record accesses (views) are logged. A reason for an update can also be recorded as part of the audit log of a record. See Audit History for details.
Note: If you initialize a database for alerting, audit history is automatically turned on. Alerting must be turned off before audit history can be turned off. 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 see alert details.

Audit log options

Depending on the type of database and your logging requirements, you can define how log data is written to the Audit Log database with the following options.

The table details how to set audit log options.
Action Description
Choose the initial level of auditing detail for a new database.

In iBase, select File>New Database>Details>Audit Level.

Change the audit level for an existing database.

In iBase Designer, select File>Database Properties>Audit Level.
Audit the usage of selected commands.

In iBase Designer, select Security>System Commands Access Control.

  • Selecting any command groups on the Reason for Action page will prompt the user for a reason for running the command. After the user supplies a reason, iBase adds the text to the audit log (as Detail). This reason will subsequently be used as a default for all subsequent reasons within the same session of work.

  • Command groups selected on the Audit page, record the action without prompting for a reason or otherwise notifying the user.

Auditing that is configured in this window applies to particular groups of users, at all audit levels, and to all databases accessed through the same security file. For more information, see System Commands Access Control Groups.
Record the history of changes to individual records in SQL Server databases

From the File menu in iBase Designer, select Database Properties. Use the Audit History check box in the Database Properties dialog box. You can also configure Audit History to disable the guest account and replace it with an existing SQL Server account for audit history logging.

For more information, see Audit History and Changing accout used to log audit history.
Activate case control in a new SQL Server database.

In the iBase window, select Create New Database and click OK. Use the Case Control option on the Advanced tab of the Advanced page to set up case control in a new database before any data has been added to it.

Activate case control in an existing SQL Server database.

From the File menu in iBase Designer, select Database Properties. Use the Case Control option on the Advanced tab.