Audit - Specific issues
These sections describe the effect of several changes you can make in the audit settings.
The effect of a change depends on the specific situation. The situations that are described arise if changes in the audit settings are converted to run time and not all users did leave LN. Then, some users create audit trails based on the old configuration. Users that start afterwards create audit trails based on the new configuration.
Changes in the profiles
This table summarizes the effect of the 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, and 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. Therefore, users with the old settings can be forced to restart LN. |
- If you switch field-specific auditing for a table on or off, and this results in a different number of fields to be audited. Then the affect 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. That host is another audit server than users with the old settings use. Therefore, the transaction IDs are not successive, and the audit trail is corrupted. The user does not notice this problem.
Changes in the directory of the sequence files
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. Therefore, the sequence numbers in the file names are no longer an indication for the sequence of the files. The user does not notice this problem.
Changes in the maximum file size 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 grows until this new size. If the file size was diminished, and the current file already exceeds this size. A new file is created the next time a transaction is logged.
Combination of changes
The changes that are 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 these advantages:
- The audit trails that are created with the new settings are not mixed with the audit trails created with the old settings.
- The users can continue their work.
Issues can still occur, beginning with the problem already described, that the sequence of the sequence files becomes unclear. A user can also start LN on the moment that the new audit settings are converted to run time. Then the user can use the new settings for the profiles, and the old settings for the directory of the sequence files.