John Oliva wrote:

I haven't worked out a synchronization scheme yet. One possibility is to
model it on how the Palm PDB databases are synchronized.  They keep
meta-data for each row indicating whether the data is dirty, new, has been
deleted, etc. This is optimized for a one-to-one pairing between two
databases.  A more complex process would be required to support
synchronization between members of a set of databases which all may be
synced.

Do you support uni-directional and bi-directional synchronization?

You mentioned that you create a hash on the contents of the row to produce
a GUID.  I presume this is only done when you first create the row,
otherwise any changes to the row data would change the GUID.  Correct?

John



Correct, the GUID is calculated on insert only. We support bi-directional synchronization between
multiple databases. Since we don't have dirty bits for each field, we only take the newest version during
any sync. So when changes are made on multiple databases between syncing, we lose all but the
newest change. For the application we are writing, it's unlikely that someone will change one field of a
row in one database and then change a different field in another. Like I said, there are some drawbacks.
I have yet to figure out how best to deal with deleting records. We have a delete flag, but with mutliple
copies of the database, it's not possible to just delete a record on the two syncing machines.


John LeSueur

Reply via email to