Transaction Database

This database holds all the information about the success or failure of the updates and remote claiming and is the first place to go to check that Global is operating successfully. Ideally it should be regularly monitored by the Administrator responsible for each location. Note that if an automated update fails for any reason, then there is always the option to perform the update manually rather than waiting for the automated update to try and align things again. By doing the update manually, the duration of locations being out of synch is reduced and also the automated update process does not get loaded with 2 or more lots of update data to deal with.

On a large and busy project the transaction database can become very large, so it should be compacted on a regular basis. The recommended method of doing this is to use the Merge-and-Purge process via the Daemon.

Daemon merge-and-purge can be done when MODEL users are in the project (but not Admin users) provided that they do not have the Transaction db in their Multiple Database (MDB). If a Module (for example, Admin) is accessing the transaction db when the merge-and-purge is attempted, then nothing will be purged.

However, if the merge-and-purge is interrupted, for example, by a crash of the Daemon, then one of the two following methods could be used at each satellite after all users are out of the project and the Daemon has been stopped: either

• carry out a normal merge (merge changes TRANSACTION/SAT). It will be necessary first to run a macro to collect and delete old commands ‑otherwise the merge will achieve nothing. AVEVA can assist with writing such a macro. An example of a similar macro you can use as a basis is shown in Example Macro for Collecting and Deleting Old Commands.

or

• rename the database (for example, ABC0001_0001 to ABC0001_0001-ORI)

• restart the Global daemon (a new clean database will be created automatically)

  The problem with this method is that incomplete transactions are lost and therefore updates are missed and this may contribute to misaligned Primary and satellite locations.

The Admin UI provides a view of the updates from the Transaction db and it is important that the administrator checks the actual messages from these Updates because the update may not have successfully updated ALL databases, although the overall command has been successful.

If the MESSAGE reads 'Update All succeeded (NNNN DBs) with MMMM failures' then the administrator MUST investigate the failures. The FAILUREs pane of the Transaction messages form indicates this. If this check is considered to be worth separating to a distinct procedure a macro may be written to collect TRFAIL elements below the TRINCO for the TIMEDUPDATES user.