Administrative concerns arise as you move components to the workstation level. For example, when you need to modify a static object in your application, such as a table’s structure or a program’s code, you must have mechanisms in place for updating all affected components on each individual workstation.
This problem can be somewhat minimized by building your application so that it checks for latest versions upon startup. For example, your application’s startup code can check the modification dates of static objects in the local database (using, for example, the DAO LastUpdated property) and compare them to dates in a central database located on the server. Whenever a newer date is found on a server object, the code automatically imports the latest version of the object, keeping the local database up-to-date.
You can also use the replication features in Microsoft Jet 3.5 to keep objects up-to-date by synchronizing them. For example, you can create replicas of the database and store them at the workstation level. In this scenario, engine replication takes care of the details of synchronizing objects.
See Also For more information about replication, see Chapter 7, “Database Replication.”