On 13 May 2003 at 14:47, kepeskrisz wrote:

>We search for the solution: so we want to try some replication.
>
>What we can do for avoid these problems ?

First of all: replication require some management decisions and
can't be done by programs only.
One of them is document resposibility: a document can be edited
only in office where it was created. So, your case B1 must not
happened.
Usually one of offices is a central one and is the only place where
reference tables can be modified.
About timestamps: don't use them. Use generators. They are
guaranteed from producing the same numbers and external interventions
(like summer-time shift).
Replication program must take into account only records that were
created/modified in current office, so every record must have office
mark and 'last modified' mark. Or you can keep log of operations for
all tables that are subject to replication.
Deletions usually disabled for distributed DBs.
Primary keys for tables which can be entered in different offices
are composite and include office mark.
Forget about on-line replication. Replication sessions should be
performed with the lowest possible rate. It can reduce traffic when
work with documents is badly organized (your case).

>Also problem: we know the order, how to be insert, and modify records.
>But the replicator don't know. If it not follow this order: the repli-
>cation is failed.

Why? You implement the replicator and definitelly can explain him
which table is "master". Or to teach him to analyse foreign key
relations.

SY, Dimitry Sibiryakov.