If you use standard or enhanced conflict detection, you must store
before-images in the CD (or CCD) tables for the replica target tables. Also,
the referential integrity rules are restricted. In peer-to-peer and update-anywhere
scenarios, or when the Apply program uses transaction mode processing, you
should define referential integrity rules that are in keeping with the source
rules. If you use peer-to-peer replication or update-anywhere replication
and you do not want to turn on conflict detection, you should design your
application environment to prevent update conflicts. If conflicts cannot occur
in your application environment, you can save processing cycles by not using
conflict detection.
Use either of the following methods to prevent conflicts in peer-to-peer
and update-anywhere replication:
- Fragmentation by key
- Design your application so that the replication source is updated by replicas
for key ranges at specific sites. For example, your New York site can update
sales records only for the Eastern United States (using ZIP codes1 less than or equal to 49999 as the key range), but
can read all sales records.
- Fragmentation by time
- Design your application so that the table can be updated only during specific
time periods at specific sites. The time periods must be sufficiently separated
to allow for the replication of any pending changes to be made to the site
that is now becoming the master version. Remember to allow for time changes,
such as Daylight Savings Time or Summer Time, and for time-zone differences.
SQL Replication