UNDERSTANDING DATABASE REPLICATION CONCEPTS
Access developers typically start with simple, single-user applications, and then progress to multiuser development. You're now ready to move up to the next level—distributed, multiuser, replicated database applications.
Access 2000 delivers replicated relational database functionality to the desktop, making feasible the development of economical and robust solutions to meet a whole new range of business applications. Replication allows users to have copies of the database at different locations; updates and insertions made in one replica propagate to all replicas.
Focusing on the Replication Design Goal
Understanding the intentions of the Access development team will help you develop successful replication applications. Some aspects of the design might initially appear obscure. Careful study of these features and tools, however, provides many opportunities to build powerful and efficient replicated database applications.
The primary design goals focused on providing a powerful set of replication features and tools for the typical Access user running a typical desktop PC configuration for Access 2000. Also, a PC environment is usually less controlled than, say, a centralized MIS operation, and many features were designed to protect less-experienced users from inadvertently getting into difficulties. The goals were as follows:
Ease of use. Any Access user can create a replicated database application.
Minimum performance impact. Try to keep performance as good for replicated databases as it is for non-replicated databases.
Transparency to end users. A replicated database application should behave in exactly the same manner as a non-replicated version of the same application. Data can be inserted, deleted, and updated in any replica.
Support of object and data replication. Objects include forms, reports, Data Access Page links, macros, and modules.
Incremental changes. Send only incremental changes at replica synchronization.
Ability to merge changes made in the same row. If changes are made to different columns in the same row, you can merge changes without conflict through the support of column-level tracking in Access 2000.
Full support for data convergence between replicas. That's because errors are eliminated in Access 2000.
Control of design changes. Allow design changes to only one replica in the replica set.
Low consistency between replicas. For example, at any time two replicas may contain different data; however, the replicas become consistent with a successful synchronization. With a design for low consistency, users don't need to maintain expensive and error-prone full-time communication links.
Distributed administration. This allows any replica to initiate a synchronization, create an additional replica, and resolve any resulting conflicts.
High latency between synchronizations. For example, replicas won't try to synchronize immediately after a data update, but at some later time.
Support for “occasionally connected” users. This includes connecting and updating laptop users.
Looking at Some Typical Replication Applications
Replicated databases offer radically new solutions to a range of common business needs:
Distributed offices. Businesses with more than one office need to share data. On the grounds of cost, reliability, and performance, it's often impractical to maintain a constant communications link between offices. Database replication allows each office to maintain a local copy of the database and synchronize on a regular basis.
Mobile users. The growth in the use of laptop computers has driven the need to take copies of data away from the office. By using database replication, a user can take a copy of the Customers Orders database to the client, construct proposals from current price lists, and enter new orders, which can then be sent to the head office at the end of the day.
Application distribution. Replication applies not only to data but also to the forms, queries, Data Access Page links, reports, and so on that make up an application. Database application developers often need to distribute updates to existing applications. Replication can provide an extremely convenient method by synchronizing the customer's copy of the database to the developer's, thereby “downloading” the latest application updates onto the customer's PC.
Load balancing. Replication is well suited to address two broad categories of load balancing. In a multiuser application, there might be too many users for a single server, in which case you could create a replica and distribute your users between the two replica copies.
The other situation is one in which, for example, one user wants to conduct intensive detailed queries on your database. Queries can be very demanding on the database engine and can severely affect performance for all other users. In this situation, it would be simple to create an additional replica for the user who's running the queries, and then he can analyze to his heart's content without affecting his co-workers.
Backups. Replication provides a simple backup solution. By scheduling exchanges between two replicas, you can ensure that a reserve copy of the database is always available if a disaster occurs to the other replica. An additional significant benefit is that replication exchanges can occur without having to take the database offline.