In the event that a networked application is experiencing client synchronization problems, and the configuration database has become corrupted, you can command VTS to regenerate a client's configuration database using the server's copy. This can be done using the Force Synchronization checkboxes that appear in the Application Properties dialog (for instructions, please refer to "VTS Developer's Guide: Force Synchronization of Client Data with the Primary Configuration Server").
An instance of the Accessor module is started at the system level for any VTS application that is run, and remains running, until VTS is stopped. It is used as a conduit to the DBSystem file (Config.DB), so that other applications can look at the database without corrupting it. Recall that two or more DBSystem calls acting on the same file at once will most likely corrupt the database, even if one is only reading and not writing (see note under DBSystem).
A synchronization problem may arise when a user deletes the Config.DB file. Since Config.DB has a copy of the DBSystem database in memory, the application will still appear to operate without error until a client requires a copy of the Config.DB file from the server. The server will refuse the client's request, causing the client to attempt to generate its own Config.DB file. If this is a client that has just acquired the application via a "Get From Server" command, it will not have any files in its directory that are included in Config.DB, so the resulting Config.DB file will be empty except for a few housekeeping entries that startup sync/online config uses. When the application is started, since no Config.DB file was sent, no files will be sent either, and the application's startup will fail with an error that the system module cannot be compiled due to a missing source file.
Please refer to "VTS Developer's Guide: Force Synchronization of Client Data with the Primary Configuration Server" for the appropriate method of resolving database and file corruption.