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 the tag properties database ("Points.mdb"). Tags are sent in blocks on a per table basis; 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 ("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. Please refer to "VTS Developer's Guide: Remote Configuration and the VTS Locking Scheme" for further information.) 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.

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

Startup Synchronization of the Primary Configuration Server

Whenever you run a remote application on the primary configuration server, while VTS is going through the startup synchronization process to ensure that the copy of the application on the primary configuration server is the most up-to-date, a dialog (similar to the one shown below) is displayed.

This process is necessary to ensure that the server has the most recent application files and data before sharing it with the client workstations. Once VTS has ensured that the application on the primary configuration server is the most current, the application can be run on the client workstation(s).

Startup Synchronization of Client Workstations

Each time you start a remote application on a client workstation, VTS must go through the startup synchronization process with the primary configuration server. During the startup synchronization process, VTS compares the application files and data on the client with the application files and data on the server. If the client application files and data are not up-to-date with those on the server, the server transmits the updated application files and data to the client. While this process is occurring, a dialog similar to the one shown below is displayed.

After the initial transference of application data (on the first occasion the application is run on the client following a "Get from Server" action), the startup synchronization process is incremental to reduce network traffic and the startup time for remote applications. This means that each time the application is run on the client workstation, the client and server compare application files and data; however, only those files and tags that the server determines to be outdated are sent to the client.

You now know that synchronization ensures that a remote application and its files and data are kept current each time the application is run, but you may wonder how this process is accomplished for those changes that occur while the application is running on both the server and client workstations. VTS keeps the application synchronized during run-time using a built-in locking scheme.

The locking scheme employed by VTS is controlled by the use of the Remote Configuration dialog that can be run from the configuration toolbox. The section that follows discusses remote configuration, the Remote Configuration dialog, and the VTS locking scheme that is employed to keep all application data up-to-date.

Sometimes, it will be necessary for you to establish an existing application on a PC that is not connected to your network. The section that follows provides information on copying an existing application to an isolated PC.