Hi !

Thanx for the informations, but I've many questions:

I have been planned this replication in 3 ways:
a./ Trigger supported Changing Tables (freqv.)
b./ TimeStamp based synchronization (days/week)
c./ Full Table/DB synchronization (weeks/months)

All of the tables have
ID,SITEID (site is an location),
MOD_DATETIME, DELETED fields.
The triggers are handles all of the modifications.
The deletions are converted to updates, and the deleted
bits are have been modifed.
This method is some solution to FK problem.
Every deletion turn (1 week/1 month) we will delete
all of the DELETED records (this modify cannot replicated,
it is do on every server).

So, I reply:

>>> SD@... 14.05.03 06:39 >>>
On 13 May 2003 at 14:47, kepeskrisz wrote:
First of all: replication require some management decisions and
can't be done by programs only.
>>>

Is this involves: the DBADMIN must be presented ?
Or must need to DBADMIN notified by the replicator about the conflicts
?

>>>
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.
>>>

Ok, I understand it - it is organizational problem: not software
problem.
But in my case the sites want to shares some of datas.
The institute handles many childs. There are two sites (locations) in
one city.
The child have been moves through these sites.

>>>
Usually one of offices is a central one and is the only place where
reference tables can be modified.
>>>

When new child has been arrived, in some cases comfortabler to create
some documents in any location, and don't want move to other location
for
this operation.

>>>
About timestamps: don't use them. Use generators. They are
guaranteed from producing the same numbers and external interventions
(like summer-time shift).
>>>

Sorry but it is not too good idea. In local server: ok. But how we get
unique
generator value in two locations ?
See this problem (extreme example, but...):
A is update record N. B is update record N. A is update record N.

When we are want to replicating N(B) to A, we must avoid the update,
because the A is modify this record after B update.

How you avoid it ? If I define an generator, the generator's value
unique,
but different in every server - so this is not the solution of
problem.

>>>
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).
>>>

Offline: in night hours ?

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

Ok, I teach it.


Thanx, and I wait for your answer:
KK