> The technical implementation of this is trivial. A one-way merge
> consists of selecting a record from one database, updating inactivated
> records, and inserting new records into the second database. A two-way
> merge is simply two one-way merges operating concurrently in opposite
> directions.

But how do you deal with cases where

(i) the user is up to date with the current databases
(ii) the user goes offline (say a local copy of the database is made)
(iii) the user edits some rows offline
(iv) meanwhile those rows are edited online in the main database
(v) the user goes back online and wants to replicate his or her changes

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?

Regards,

Lauchlan Mackinnon