Many developers will find replication an ideal method for distributing application updates to their users. It's tempting to
Tip
Move the Design Master to one of the stars. Now you, as the application designer, can control when you synchronize with the hub, which will then distribute your application to the other replicas. You can fully test your design modifications in a controlled environment before propagating them to all your users.
Also, if you make your Design Master the hub in a star and hub topology, users will be offered the choice of moving the Design Master to their replica when they synchronize. If the Design Master isn't at the hub or a public network share location, users can't initiate a synchronization with the Design Master and can never make unauthorized global design changes.
For additional protection and control, make sure that the Design Master isn't on a public network share. If other replica users don't have network file read permission for the location of the Design Master, they can't initiate an unauthorized synchronization.
Objects that are propagated around all replicas are termed replicable objects. Objects that exist at a single replica are termed non-replicable, or local, objects.
If you create a new table or query in the Design Master, it will be made local by default. If you want to propagate the table or query, you must set its property to Replicable (right-click the object in the database container window, choose Properties, and then select the Replicated check box).
Tip
A very common mistake is to create a new table in the Design Master and then synchronize with a replica and expect the new object to appear at the replica. When the table isn't seen at the replica, the assumption is that replication isn't working. You must set the object's property to Replicable before it will propagate from the Design Master to other replicas.
A new feature within Access 2000 affects the replicability of Access objects (forms, reports, Data Access Page links, macros, and modules). In Access 2000, all Access objects are stored in a single binary large object (BLOB) within the database file. Therefore, all Access objects are either replicable or local, which must be specified before making the database replicable. In this new format, an individual Access object can't be identified or tracked by replication. So if the Access project in the Design Master is made replicable, all Microsoft Access objects are made replicable and synchronized if any single object is modified. When the Access project is marked replicable, project objects cannot be created or modified in any replica except the Design Master. You can choose not to make the Access project replicable before making the database replicable by setting the ReplicateProject property in the custom database properties to False. In this case, the Access project in each replica isn't replicable, and all Access objects created in a replica are local.
Note
If the Page object is replicable, the Data Access Page link (.htm file) must be stored on a network so that the page can be accessed from the Design Master and all replicas in the replica set.
Enforced relationships between tables are permitted only when both are replicated or when both are local. You can't have an enforced relationship between a local and a replicated table.
Partial replicas allow the creation of replicas with data subsets. This contrasts a full replica, which contains all the data. Partial replicas are particularly useful where users at certain sites either don't need all the data (for example, if they're a provincial office and don't need the data for the whole organization), or if they have restricted hardware, such as a laptop.
You create a partial replica by setting a filter on one or more tables and defining the relationships that should be applied to extract the data from the other tables in the database.
A partial replica can be created either through JRO code or by using the Access 2000 Partial Replica Wizard.
The easiest way to get started with partial replicas is to use the Partial Replica Wizard.
By using the wizard, you first select one table on which you will apply a filter. Let's call this the focus table. Apply one or more filters to the focus table, and then select the relationships between the focus table and the other tables in the database.
Note
The Partial Replica Wizard restricts you to filters on a single table. For more complex filter criteria, you must use code.
For example, using the Northwind database that ships with Access 2000, follow these steps:
1. |
Make the database replicable by choosing Replication and then Create Replica from the Tools menu. |
2. |
To use the Partial Replica Wizard, from the Tools menu choose Replication and then Partial Replica Wizard (see Figure 23.6). Figure 23.6. The Partial Replica Wizard guides you through creating a new partial replica or modifying an existing partial replica. |
Note
You can create a partial replica from a full replica with global visibility, if you use the wizard. Otherwise, if you create the partial replica in code, visibility can also be local or anonymous. You can't create a partial replica from another partial replica.
3. |
Select Create a New Partial Replica and an appropriate filename for the partial replica. You can either accept the suggested filename (Partial Replica of <filename>) or enter another name. |
4. |
Select the table that will have the filter expression (for example, Categories). |
5. |
Note
Partial replica filters don't support user-defined expressions.
6. |
Specify the data to include for the other tables in the database. The default is to select all records. Remove the check mark to select only those records related to those specified by the filter, thereby creating a smaller partial replica. |
It's strongly advised that you create a report, because you might need to refer to it at a later date.
Tip
Using the filter expression in the replica description—for example, Nwind where Category ID > 1—helps you remember how each replica was created, and assists you when troubleshooting the replica set at a later date.
Note
A partial replica actually contains all the tables of a full replica. The filter simply restricts the number of rows in each table—therefore, some tables might be empty.
JRO programming allows a more flexible approach to creating partial replicas, allowing filters on more than one table.
Note
There are restrictions on using the Partial Replica Wizard for editing a partial replica's filter that has been created by using JRO. If the replica has a complex filter that has been created by using JRO, the wizard will warn you, and the complex filter will replaced by the wizard's single table filter expression.
Creating a partial replica is a four-step process:
1. |
Create the replica and identify it as a partial replica. (At this stage, it has all the tables defined, but no data.) |
2. |
Create the filters for the tables. |
3. |
Define the filter relationships. |
4. |
Listing 23.6 shows the code for creating the partial replica.
You must set a filter for each table that has the data you require. The default is to supply no rows for each table; if you don't set a filter for a particular table, you don't get any rows. Remember, a partial replica is created empty. Only by setting filters and relation properties can you populate the partial replica with data rows.
Again, if you don't specifically set the relationship filter, the default is false, which means that there are no data rows in the related table.
Note
You must synchronize from a partial replica to a full replica. You can't synchronize between two partial replicas.
When you combine filters in a partial replica, they create a logical OR result. For example, if you set two filters—for Customers where Region = 'CA' and Orders where Value > 100—you get records for all customers from California and all records for orders where the value is greater than $100.
3.139.83.96