Operational Change Propagation

Operational changes are propagated in different ways under different circumstances. It is important to understand these differences in order to comprehend which data will prevail in the event that network issues arise during operational changes.

Primary Configuration Server Available

If the primary configuration server (see Primary Configuration Server) is operating normally, propagation of operational changes will proceed normally, with the operational changes being updated on all workstations running the application.

Primary Configuration Server Unavailable – Backup Server Available

If the primary configuration server has failed, and a backup server (see Backup Servers) is enabling the application to run, all workstations will receive operational changes. However, if the primary configuration server had an operational change pending for a tag or file, the operational change on the primary configuration server will override the operational change propagated by the backup server while the primary configuration server was unavailable. Such modifications are rolled back and discarded.

No Server Available (Neither Primary Configuration Server Nor Backup Server)

In the event that no server is available (neither the primary configuration server, nor any backup server), and an operational change is performed on the local workstation, the operational change is made locally. When a connection with a server is re-established, if the selected tag or file was not changed on the server's side, the operational change made by the local workstation is propagated to all workstations running the application (as it would be under normal circumstances – see "Primary Configuration Server Available" above).

However, if the server modified the tag or file, the operational change on the local workstation is rolled back and is discarded.

This has the further implication that if two isolated clients do an operational change on the same tag, the first one to do an Edit Lockout Manager service synchronization is the one whose operational change will prevail. When the second client gets synchronized, the server will have already seen the first client's operational change, which will be indistinguishable from a change having been made on the tag in the client's absence.

In addition to making changes to a running remote application's files and data using operational changes or configuration changes, it is possible to make changes to a remote application when it is not running. These changes are known as offline changes and are discussed in the section that follows.