Notifications that fail to properly clear themselves after the issue is resolved can be manually cleared.

This clearing action will remove the notifications but will not clear the cause of the events! It is to be expected that the monitors will detect the problem and report it again. The different means of clearing the Events is intended to remove persistent notifications that have been resolved but are not detected as such by the monitors.

System events can be removed by two methods. The first is by means of the 'Admin - System - System status' tool.

Under the 'Server' caption of the report a section on 'System events' can be found. It lists the current Event records for the selected server and a [Clear events] button.

This 'Clear events' button will remove the Event records from the database for the selected server. To clear all, the action must be repeated for each server.

Note This method of clearing connects to the database that is LOCAL to the selected server. When database replication failed the content of each database was only updated on the local database. The reported events are then also only local. Be aware that clearing events for one server could lead to replication errors later on.

The second means to correct notifications is by altering data in the database.

The System events statuses are stored in the YCE database using the table Yce_servers. This table maintains several server specific records among which are the System events.

The column Database_name is used to hold the System event name as was mapped from the specific monitor using the configuration file.

One record for every System event name per server can be present in this table. The columns 'Msg_type', 'Severity' and 'User_level' correspond to the events' attributes in the configuration file. The 'Server_status' column has the actual event message.

Using the direct table access tool under 'Admin - Custom data' and selecting the Yce_servers table, the data can be modified to suit the situation.

Note Be aware that the database these modifications are executed on are NOT necessarily the LOCAL database as in the above method. The changes are applied to the current active database. In case of replication failures the changes performed here could lead to replication conflicts after the synchonization is to be re-established.