Startup Synchronization

Every time you run a remote application on a client workstation, VTS goes through a process to ensure that the client obtains the most up-to-date copy of the primary configuration server's data (including database data). This process is called "startup synchronization".

The first time that the application is run (or compiled – see note below) on the client workstation, the primary configuration server makes a copy of its tag properties database ("Points.mdb"), strips out the data so that the database is empty, and then transmits the empty tag properties database to the client. Next, the primary configuration server packages the tag data from its copy of the tag properties database and sends it to the client workstation where it is added to the client's copy of "Points.mdb". Tags are sent in blocks on a per table basis and then files are transferred.

The primary configuration server also sends a complete copy of the configuration database ("Config.db") to the client the first time the application is run.

The client generates its own blank copy of the replica tag database ("SCT.mdb"). When the application is run for the first time, the primary configuration server populates SCT.mdb with a copy of its data.

On each subsequent occasion that the application is run, VTS performs the startup synchronization process to ensure that the primary configuration server and all clients maintain up-to-date copies of application data. This process involves less data transference than the startup synchronization process, as the server transmits only modified data from the server to the client(s). This is accomplished by the comparison of "revision values" (i.e. the date and time of the last modification of each item).

The configuration database (see Configuration Database (Config.db)) contains all of the locking information for a remote application. (The VTS locking scheme ensures that only one user has permission to edit a resource at a time, as discussed in Remote Configuration and the VTS Locking Scheme). Online file changes cause one or more revision values stored in the configuration database to be updated. VTS compares the revision values on the client's data to those on the server's data, and sends only those files that have changed to the client.

In a similar manner, VTS compares revision values in the server's copy of the replica tag database ("SCT.mdb"), with those in the client's replica tag database, and sends the updated tag data to the client.

Offline tag changes are detected when VTS compares the last-known copy of the tag (in the replica tag database ("SCT.mdb") with the current copy in the tag properties database ("Points.mdb"). If VTS detects a difference between the two files, the loader attempts to lock the tag for updating. This process is based on changes in data rather than the timestamp. Further details on offline changes are described in Offline Changes.

The sections that follow identify synchronization as it applies to the primary configuration server, and to the client workstation(s).