User's Manual

Replication errors and conflicts
SQL Remote is designed to allow databases to be updated at many different
sites. Careful design is required to avoid replication errors, especially if the
database has a complicated structure. This section describes the kinds of
errors and conflict that can occur in a replication setup; subsequent sections
describe how you can design your publications to avoid errors and manage
conflicts.
Delivery errors not discussed here
This section does not discuss issues related to message delivery failures.
For information on delivery errors and how they are handled, see “The
message tracking system” on page 237
Replication errors
Replication errors fall into the following categories:
♦ Duplicate primary key errors Two users INSERT a row using the same
primary key values, or one user updates a primary key and a second user
inserts a primary key of the new value. The second operation to reach a
given database in the replication system fails because it would produce a
duplicate primary key.
♦ Row not found errors A user DELETES a row (that is, the row with a
given primary key value). A second user UPDATES or DELETES the
same row at another site.
In this case, the second statement fails, as the row is not found.
♦ Referential integrity errors If a column containing a foreign key is
included in a publication, but the associated primary key is not included,
the extraction utility leaves the foreign key definition out of the remote
database so that INSERTS at the remote database will not fail.
This can be solved by including proper defaults into the table definitions.
Also, referential integrity errors can occur when a primary table has a
SUBSCRIBE BY expression and the associated foreign table does not:
rows from the foreign table may be replicated, but the rows from the
primary table may be excluded from the publication.
Replication conflicts
Replication conflicts are different from errors. Properly handled, conflicts
are not a problem in SQL Remote.
88