> > I would have presumed you'd need a logic of deciding which changes
> take
> > precedence. For example, if the online changes take precedence,
> perhaps you
> > have to come back to the user and say you can't commit changes to
> row 123456
> > because someone has changed that row online. the new data is . . .
> what do
> > you want to do?
> >
> > I think an n-tier framework would make supporting this kind of
> replication
> > logic much easier. What is your strategy for handling these cases?
> >
>
> In our particular model this is not an issue, obviously if you need
> to provide auditing information then you should take heed of David's
> advice on the matter. My solution would certainly not be adequate for
> that, however developing a model such as David's would have been
> overkill for our task.
>
> Lauchlan, I don't think David's solution introduced any additional
> complexities to the "dirty update" problem. Whenever data is taken
> out of the live DB and put back in later, you need to deal with that
> problem. It is a business rule rather than a technical consideration.
> If the synchronisation is automated, then the decision is something
> like:
>
> * Live DB always wins
> * Offsite DB always wins
> * Oldest change always wins
> * Newest change always wins
> * Some hybrid that attempts to merge changes
>
> Every one of these except the last is trivial to implement.
>
> Adam

just as an example - the old Tclientdataset demo source used to have a a
conflict form which jumps up for the user to arbitrate between
fields/records of the merge. IME, users freak out with this and never want
to commit to ruling their change as the winner.
You will have to come up with some way of expressing your arbitration rules
yourself as Adam suggests and this depends largely on the sustem and what
the users can feel happy about.
Alan