Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Engineering

Creating Update Events

  • Last UpdatedNov 27, 2025
  • 3 minute read

For automatic updates to take place, you must create an Update event between pairs of locations. The locations can have a parent-child relationship, or they can both be members of the same group. Only create the Update event at one of the locations in the pair.

When considering the timing of Update events, it is better not to have a location taking part in two events at the same time. For example, if there is a chain of locations AAA - BBB - CCC, and hourly updates are required, create an Update event between AAA and BBB on the hour, and an Update event between BBB and CCC on the half-hour.

The timing of Update events is particularly important between the members of a group.

Note:
Update events only control the frequency with which model databases are updated. When commands affect the Global or System databases, the changes to the databases are propagated as quickly as possible to the required locations.

To create an Update event, select Updates from the Elements button on the Admin Elements window, click Create, to display the Create Update Event window.

Fill in a Name, which must be fewer than 32 characters long and unique within the project location.

The Description is optional. It can be up to 120 characters.

The Update Location list shows all the locations that can share an update event with the current location. They are on-line locations which are one of the following categories:

  • The parent location of the current location.

  • A child of the current location.

  • A member of the same location group as the current location. Refer to Location Groups, for information on groups.

    The gadgets in the Update Settings frame relate to the parameters of the communications process.

The Suppress Scheduled Updates check box, controls whether or not scheduled updates are suppressed. By default, updates are not suppressed.

The Frequency text box controls the frequency at which updates will take place. These may be daily, hourly, weekly, monthly or a combination. The value entered consists of five fields which are separated by spaces. The button immediately to the right of the text gadget allows the field values to be specified separately using several child forms.

Max. Retries can be set to a number between 1 and 100. This is the number of retries the communication daemon will make in the event of unsuccessful communications.

Retry Interval can be set to a value in the range of 1 to 14400. This value is the time in seconds between communication retries. If the communications daemon cannot connect to the remote location, it will wait this number of seconds before attempting to reconnect. It will continue to attempt to reconnect until the maximum number of retries is exceeded.

Note:
Max Retries and Retry Interval on the Update event are ignored in Global WCF since configuration file settings are used instead.

Transfer Scripts

Enter the names of script files in the two Transfer Script text boxes. The scripts are run Before or After the update procedure. The scripts are optional and they do not both have to be set.

The scripts could be used, for example, to transfer selected plotfiles.

When a script is run it will be supplied with two arguments, the three-character ids of the current location (A) and the remote location (B), in that order.

It is possible to run scripts at the remote location. To do this, create an update event at the current location with the Frequency text box left blank, and the Transfer Scripts text boxes filled in. When an update occurs between A and B, the scripts will be run at B. The arguments will be reversed (B, A).

Note:
When an Update event is created or deleted, it may take some time to come into effect. There is a possible delay of up to 15 minutes before the update information is re-read from the System database. If necessary, this delay can be reduced by stopping and re-starting the daemon.

In addition to the above, the transaction database will also be checked regularly for stalled commands.

Databases can be updated manually. Refer to Unscheduled Updates for more information.

TitleResults for “How to create a CRG?”Also Available in