Subject | Re: [firebird-support] Re: Replicating user data |
---|---|
Author | Alexandre Benson Smith |
Post date | 2005-06-27T04:28:33Z |
Lauchlan Mackinnon wrote:
For insert and update just the record ID and action is ok.
But for update
Record ID 123 is modifed, so it's need to be synced to the live db
Check Live DB, ops record 123 is modified too... :-(
I will add the column Name, so when replicating I will check
Record ID 123 is modified, Column A is modified.
Check the Live DB, record 123 was modified too, but columnB, so I could
updated Column A without fear to lose other changes.
If the same column was modifed on both, then the conflict resolution
should get in action.
The major problem I see on replication is:
I have a Table Product and a Table StockMovement.
Every new record on table StockMovement start a trigger that update
column Quantity on table Products.
then lets assume this scenario:
Product A has Quantity = 10
DB's are synced, user goes off line
Off line the user add a record to table StockMovement selling 3 units of
Product A at 3:00PM
On line another user add a record to StockMovemente selling 2 units of
Product A at 5:00PM
The Off line DB has the table Product indicating 7 units
The On line DB has table Products indicating 8 units
At 6PM the users connects back I the syncronization starts.
When I sync the both I will get a conflict, but what is the correct
information 7 or 8 units of product A ? neither, the correct quantity is
5 units of product A, how do you guys handle this situation ?
It's valid not just for off line DB's syncronization, it valid for
multiple offices with a centralized Stock too, or for back accounts, etc.
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.1/28 - Release Date: 24/06/2005
>Suppose you choose LiveDB wins, and set out to do the replication. By thisI will add some more info to the delta, so the conflicts could be minimized.
>rule, some of the records can be replicated to the live DB and some cant.
>Suppose for the sake of discussion, we keep track of the offline 'delta'
>with three fields, NeedsUpdateToServer (boolean), ActionType (the latter can
>be 'update', 'insert' or 'delete'), and LastModfiedTimeStamp. And yep I know
>you could use just the datetime stamp and a record of the time last
>replicated to server to achieve much the same result.
>
>ok, so given this we can get the delta by select . . . where
>NeedsUpdateToServer = true, returning the delta as a dataset.
>
>
For insert and update just the record ID and action is ok.
But for update
Record ID 123 is modifed, so it's need to be synced to the live db
Check Live DB, ops record 123 is modified too... :-(
I will add the column Name, so when replicating I will check
Record ID 123 is modified, Column A is modified.
Check the Live DB, record 123 was modified too, but columnB, so I could
updated Column A without fear to lose other changes.
If the same column was modifed on both, then the conflict resolution
should get in action.
The major problem I see on replication is:
I have a Table Product and a Table StockMovement.
Every new record on table StockMovement start a trigger that update
column Quantity on table Products.
then lets assume this scenario:
Product A has Quantity = 10
DB's are synced, user goes off line
Off line the user add a record to table StockMovement selling 3 units of
Product A at 3:00PM
On line another user add a record to StockMovemente selling 2 units of
Product A at 5:00PM
The Off line DB has the table Product indicating 7 units
The On line DB has table Products indicating 8 units
At 6PM the users connects back I the syncronization starts.
When I sync the both I will get a conflict, but what is the correct
information 7 or 8 units of product A ? neither, the correct quantity is
5 units of product A, how do you guys handle this situation ?
It's valid not just for off line DB's syncronization, it valid for
multiple offices with a centralized Stock too, or for back accounts, etc.
>Lauchlan Mackinnonsee you !
>
>
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.1/28 - Release Date: 24/06/2005