Subject | Re: [ib-support] IBReplicator bugs |
---|---|
Author | Paul Beach |
Post date | 2001-11-05T10:19:35Z |
From Vince Duggan:
Ulrik,
You are correct as far as the TimeStamped conflict resolution is concerned,
but your understanding of Priority based conflict resolution is incorrect.
I will send you the latest build of the Replication Server for IB6 in a
separate mail, which will solve your timestamped conflict resolution
problems, and I will post the updated software to our website in the next
few days.
As far as priority based conflict resolution is concerned:
Priority Based Conflict Resolution does not come into operation until there
is a conflict. A conflict happens when a row is being replicated from A to B
(A has a lower priority than B) and:
The operation is an INSERT, and the row already exists on the target
OR
The operation is an UPDATE and the row does not exist on the target.
You can see from the above, that (taking the example of an UPDATE) if the
row exists, it will be updated, and it doesn't matter what the priority is.
This means that a low priority database can replicate to a higher priority
database. The time of the data change is not relevent when using Priority
Based Conflict Resolution .
If both source and target databases have updated the same row, more or less
at the same time, *there is no rule which can be defined* which will work
for everyone all the time. There is no way for the software to decide which
row is the 'correct' one. The Replication server applies some simple rules
only so that the data administrator can be sure that the same rule is
applied each time, but it does not guarantee that the 'correct' change got
replicated.
Timestamped conflict resolution can just as easily replicate the 'wrong'
row, since nobody can guarantee that the later change is always the best
one.
If you need more control, then you need to replicate via stored procedures,
but I can assure you, at some point you will discover that you will come
across a situation where your stored procedure cannot decide which row to
replicate, and human intervention (Manual Conflict Resolution) is required.
Vince
Paul Beach
Main Tel (UK):+44 (0) 1844 354465
Mobile: (UK): +44 (0) 7764 188603
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information
Ulrik,
You are correct as far as the TimeStamped conflict resolution is concerned,
but your understanding of Priority based conflict resolution is incorrect.
I will send you the latest build of the Replication Server for IB6 in a
separate mail, which will solve your timestamped conflict resolution
problems, and I will post the updated software to our website in the next
few days.
As far as priority based conflict resolution is concerned:
Priority Based Conflict Resolution does not come into operation until there
is a conflict. A conflict happens when a row is being replicated from A to B
(A has a lower priority than B) and:
The operation is an INSERT, and the row already exists on the target
OR
The operation is an UPDATE and the row does not exist on the target.
You can see from the above, that (taking the example of an UPDATE) if the
row exists, it will be updated, and it doesn't matter what the priority is.
This means that a low priority database can replicate to a higher priority
database. The time of the data change is not relevent when using Priority
Based Conflict Resolution .
If both source and target databases have updated the same row, more or less
at the same time, *there is no rule which can be defined* which will work
for everyone all the time. There is no way for the software to decide which
row is the 'correct' one. The Replication server applies some simple rules
only so that the data administrator can be sure that the same rule is
applied each time, but it does not guarantee that the 'correct' change got
replicated.
Timestamped conflict resolution can just as easily replicate the 'wrong'
row, since nobody can guarantee that the later change is always the best
one.
If you need more control, then you need to replicate via stored procedures,
but I can assure you, at some point you will discover that you will come
across a situation where your stored procedure cannot decide which row to
replicate, and human intervention (Manual Conflict Resolution) is required.
Vince
Paul Beach
Main Tel (UK):+44 (0) 1844 354465
Mobile: (UK): +44 (0) 7764 188603
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information