On each subsequent occasion that the application is run, VTS performs a 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 – see 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). 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 – see 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.