Execute Archive/Load Scripts

QAD 2017 Enterprise Edition > User Guides > Security Administration > Auditing > Archive Database > Execute Archive/Load Scripts

Before auditing records can be moved from a source database into the archive database, the source database and the archive database must have auditing enabled.

To move auditing records from all databases enabled for auditing, execute the command:

> yab database-auditing-archive

Alternatively, to move auditing records out of a specific database, execute the following command, where INSTANCE is the name of the source database:

> yab database-[INSTANCE]-auditing-archive

The archive command consists of two steps:

1 Audit records are exported into a directory within build/work/auditing, which removes the records from the source database.

2 The records are loaded into the archive database.

The audit records in the work directory are not deleted when the command completes as a precaution to allow the records to be reloaded if the second step fails. If a failure occurs, you can specify the (-audit.workdir) option to locate the work directory containing the audit records to load. When the archive process is successful, the work directory can be removed.

The following settings configure the operation of the archive command:

# The account to use when archiving audit data or empty to use the current OS account.

# NOTE: If an audit.user is not configured the 'Audit Administrator', 'Audit Data Archiver', and 'Audit Data Reporter' roles will be granted to the OS account that was used to create the database so auditing functionality works out of the box. If an audit.user is configured we assume we are working in a restricted environment where auditing authorization will be handled directly using the Progress data dictionary.

audit.user=

# The password for the audit.user account.

audit.password=

# The database where archived audit records will be stored.

audit.archive.database=db.qadarc

# The directory where exported audit records will be stored.

audit.archive.dir=${appdir.work}/auditing

Note: If the audit.user was not defined when the environment was created, the operating system account that was used to install the environment needs to be set up as an application user to configure auditing within the application. To configure audit users and roles that provide a better segregation of responsibilities, see Configure Database Options and Audit Permissions.