Audit - Specific issues

The following sections describe the impact of several changes you can make in the audit settings. The impact of a change depends on the specific situation. The situations described arise if changes in the audit settings are converted to run time while not all users did leave LN. As a result, some users create audit trails based on the old configuration, while users that start afterwards create audit trails based on the new configuration.

Changes in the profiles

The following table summarizes the impact of the changes for a particular table in a company:

Impact of changes for a particular table in a company
Change	Consequence
Add a table.	Users that still use the old settings do not audit some transactions.
Remove a table.	Some transactions that must not be audited with the new settings are still audited by users that use the old settings.
Change the audit type for a table or field.	Some transactions are audited according to the old settings, while other transactions are audited according to the new settings.
Add or remove a field.	After you audit transactions in the table with the new settings, users that use the old settings can no longer perform transactions on this table. As a result, users with the old settings can be forced to restart LN.

Notes

If you switch field-specific auditing for a table on or off, and this results in a different number of fields to be audited, the impact of this change is the same as adding or removing a field.
Not every change in the audit settings results in other settings at run time. If you convert the new settings to run time, the net result of the changes for the entire configuration might be zero.

Changes in the audit host

An important part of the audit trail is formed by the transactions IDs. To be useful, the transaction IDs must be successive. The transaction IDs are generated for each combination of table and company by the audit server, which runs on the audit host. If the audit host settings change, users with the new settings use another audit host, and, therefore, another audit server than users with the old settings. As a result, the transaction IDs are not successive, and the audit trail is corrupted. However, the user does not notice this problem.

Changes in the directory of the sequence files

If the directory where the sequence files are stored is changed, users that use the old settings can still create new sequence files in the old directory. As a result, the sequence numbers in the file names are no longer an indication for the sequence of the files. However, the user does not notice this problem.

Changes in the maximum file of the sequence files

If the maximum file size of the sequence files is changed, and this change is converted to run time, the new file size is immediately effective, both for users with the old settings, and for users with the new settings. If the file size was enlarged, the current file will grow until this new size. If the file size was diminished, and the current file already exceeds this size, a new file will be created the next time a transaction is logged.

Combination of changes

The changes described in the previous sections can also be combined. A combination of changes can have several advantages. A noticeable example is the combination of a change in the audit profile and a change in the directory where the sequence files are stored. This combination provides the following advantages:

The audit trails created with the new settings are not mixed with the audit trails created with the old settings.
The users can continue their work.

Note, however, that problems can still occur, beginning with the problem already described, that the sequence of the sequence files becomes unclear. However, a user can also start LN on the moment that the new audit settings are converted to run time. As a result, the user can use the new settings for the profiles, but the old settings for the directory of the sequence files.