Well Robert,

Since you're interested :), imagine a diamond company ... with sites in Antwerp, Tel Aviv and New York. The account related table is not difficult to manage (I think) but what keeps me awake at night are the internal inventory operations like sorting and mixing goods, where part of the information is on the site (the actual weights for example), but sometimes estimation prices are established somewhere else at a different time ... and in the meanwhile the goods may have to be shipped to a third site that may already have partially sold it.

I understand that this is more a challenge for the organisation than for software development, but you understand that all the help I can get is welcome _before_ I start to spec the problem out.

Thanks,

Marc


>>Hi,
>>
>>Could anybody point me to litterature or anything about multi site offline systems that are synchronized a bit like palmtops, periodically.
>>
>>Practically it concerns a company that has multiple sites situated on different continents but using a common database: clients, inventory, etc.
>>
>>How do you solve problems of duplicate keys, conflicting information entered at different sites etc.
>>
>>TIA,
>>
>>Marc
>
>Marc - another ref for you: ISBN 0-201-42277-8 Database systems has a good discussion of the problems with distributed databases and concurrency control.
>
>As Dragan says, physically synchronising records isn't too hard but it is unlikely to be able to be implemented blind: i.e. your synchronisation routines may have to 'know' more about the database structure/logic than (say) a third-party tool would.
>
>Duplicates:
>-----------
>For what my opinion is worth, I agree with Dragan in that duplicate or almost-duplicate records can really only by solved by human intervention (hope I'm not misquoting you Dragan!): you can perform some searches and flag those records that might be problematical but that's about as far as you can go. Mind you, it's possible for this problem to occur in single-user databases: e.g. "XYZ Ltd", "X.Y.Z. Ltd" and "XYZ Limited"
>
>Other things to watch out for:-
>
>Deleted Reference
>-----------------
>Site 1:
>A reference is made to a record in a second table (r2).
>
>Site 2:
>Record r2 is deleted.
>
>Changed capabilities:
>---------------------
>Site 1:
>Record r1 is, according to a flag, allowed to be assigned as (say) an author.
>
>Site 2:
>Record r1 is modified so that it is no longer allowed (say) to be an author.
>
>Modified data:
>-------------
>Site 1
>Record r1 is modified and a major descriptive value is changed (e.g. Pounds to Dollars)
>
>Site 2
>A reference is made to r1 by a user relying on the 'current' description (e.g. Pounds).
>
>Although a synchronisation is perfectly acceptable, the record's meaning has completely changed (even though the primary key has not, etc.)
>
>
>
>Keep us informed - please!