Replication errors and conflicts
SQLRemote is designed to allow databases to be updated at many different
sites. Careful design is required to avoid replication errors, especially if the
databasehas a complicated structure. Thissection describes the kinds of
errorsand conflict that can occur in a replication setup; subsequent sections
describehow you can design your publications to avoid errors and manage
conflicts.
Delivery errorsnot discussed here
This section does not discuss issues related to message delivery failures.
For information on delivery errors and howthey are handled, see “The
messagetracking system” on page 237

Replication errors

Replicationerrors fall into the following categories:
♦Duplicateprimar y keyerrors Twousers INSERT a row using the same
primarykey values, or one user updates a primary key and a second user
insertsa primary key of the new value. The second operation to reach a
givendatabase in the replication system fails because it would produce a
duplicateprimary key.
♦Rownot found errors Auser DELETES a row (that is, the row with a
givenprimary key value). A second user UPDATES or DELETES the
samerow at another site.
Inthis case, the second statement fails, as the row is not found.
♦Referentialintegrity errors Ifa column containing a foreign key is
includedin a publication, but the associated primary key is not included,
theextraction utility leaves the foreign key definition out of the remote
databaseso that INSERTS at the remote database will not fail.
Thiscan be solved by including proper defaults into the table definitions.
Also,referential integrity errors can occur when a primary table has a
SUBSCRIBEBY expression and the associated foreign table does not:
rowsfrom the foreign table may be replicated, but the rows from the
primarytable may be excluded from the publication.

Replication conflicts

Replicationconflicts are different from errors. Properlyhandled, conflicts
arenot a problem in SQL Remote.
88