Replicating the audit log

It is optional whether the audit logs for the database and security file are replicated. The audit logs for the database and security data are replicated separately.

The audit logs are optionally replicated:

If the audit data for the database and security file is replicated, authorized users at any site can review all activities.
If the audit data for the database and security file is not replicated, the audit logs records activity for the local database and security file only. The main effect of this is incomplete information on how conflicts between entity and link records, and in the security data were resolved. For example, log entries for the Conflict Viewer are only recorded in the audit log for the publication database (if the audit level is set to 4 or 5).

Note: The dates and times that are shown in the audit log are local to the server on which the user was working.

Filtering the audit log for the database

In a replicated audit log, the best way of filtering the log entries for a specific site depends on how user names and locations are defined in your organization:


Filter by	Description
User name	The user name might be a useful way of filtering the audit log if each user name contains an element to identify the site at which the user works.
Network Login	If users are restricted to logging on to the database on the local server, then the network login can indicate the location of the user.
Location	Locations can be a useful way of filtering the audit log if all user accounts have a location and that the location names are consistent. Note: Filtering by location does not identify the records, which a user owns (if you are using owner hyperlink fields), only those records that they create or update.

Viewing log entries for conflict resolution

There are two actions for the Conflict Viewer: Conflict Detected and Conflict Resolved. These are recorded if the audit level of the publication database is set to 4 or 5.

Two examples showing the audit trail for these actions are included in the following information.

Note: All dates and times for the Conflict Detected/Resolved records are the SQL Server date/time on the Publisher as conflicts are always detected and resolved in the publication database.

Viewing the audit log for the security file

In addition to the standard entries for non-replicated databases, the audit log for the security file records changes to group and user names that results from resolving duplicate names in the Security Manager.

The site to which a user belongs is identified by the name of the user that created it.

The site to which a group belongs is identified by the group ID which contains the database identifier.

The first site to create the user or group keeps that user or group with the permissions they defined. The user or group at the second site is treated as a duplicate and loses any defined permissions.

For example:


Date/time	User	Action	Detail
09:35:09	Sub1Admin	Create User	User SmithT created
10:06:04	PubAdmin	Create User	User SmithT created
16:00:00	Sub2Admin	Change User	User SmithT renamed to *1* Note: The user Sub2Admin displayed the Security Manager which detected this duplicate and automatically renamed it.
17:05:06	PubAdmin	Change User	User *1* renamed to 03SmithT Note: The SmithT created by Sub1Admin is kept with permissions assigned by Sub1Admin. The other SmithT is treated as a duplicate (and its permissions are ignored).

Archiving audit log files

You can archive audit log files in the usual way. It is not necessary to stop or disable replication to do this. However, notice that although the entries you delete are deleted from the audit log at all sites, the archive file is not replicated.

To make the archived entries available to all sites, you should load the archive file into the database by using the replication File Manager.