Thorough planning is necessary before setting up auditing and will save you a considerable amount of time. You should take into account certain system constraints when deciding which tables to enable for auditing. These planning considerations include:

Since most of the application data resides in the qaddb database, you should usually only audit-enable this database. However, you must also audit-enable the qadadmin database if you want to audit EDI tables such as the following:

Most tables can be audited. However, some tables, such as those with a field type of raw or blob, cannot be audit-enabled due to technical limitations. For example, OpenEdge will generate a serious runtime error if you try to audit-enable any table with a field of the raw or blob data type. The system prevents you from enabling such tables for auditing, whether they are standard or custom tables. Audit Configuration Maintenance (36.12.13.5) will not show such tables and therefore cannot be audit-enabled. The same applies to Audit Configuration Report (36.12.13.6). As a result, you cannot see such tables in the report.

You might have to consider the performance overhead when deciding which tables to audit. The overhead depends on how many tables are audit-enabled and how often they change. As a rough guide, enabling auditing can cause the disk I/O for a table to increase two to three times. You usually only audit-enable those tables needed to meet your auditing requirements.

Before you audit-enable tables in a production database, QAD suggests that you validate your table audit selections in a test environment. This could include running simple tests to verify the data you need to audit is correctly collected and reported. This can eliminate unnecessary impact on your application if your table audit selections do not work as expected. If the test results are satisfactory, you can export the QAD main policy and load it into your production database.

You must set up the archive database to store the audit trail data to prevent the application database from growing unnecessarily large. Loading audit trail data into a dedicated archive database also has the advantage that it will not impact the performance of the application database when a lengthy audit report is generated from a separated database. You might consider distributing the audit trail data across a number of databases by date range. For example, you can create one archive database for each month, quarter or year, depending on the volume of audit trail generated in a particular period.

Auditing custom tables is just like auditing the standard tables—provided that the custom table schema follows QAD’s convention. The primary keys should be meaningful data items so that they can serve as identifying fields for audit trail. Again, the only constraint is that you cannot audit-enable a table with any field of data type raw or blob.