>
>
>Hmm. Courageous post. :)


>I thought that to the contrary, as in this case the conflicts are likely to be multiple and will require manual interventioin, I thought that a more robust DBMS would not really make the difference.
>
>I'll order the book. :)
>

>Thanks for caring.
>
>Marc

If you extend the locking model, you shouldn't need ANY human intervention (well...) - consider using a 'primary copy' of a record and, in order to edit it, you must 'have' it locally.

E.g., think of a normal multi-user database and pessimistic locking: only one user 'has' a record (in the memory of their PC if you like), the others have on-disc copies (they only know this if they attempt to edit the record, in which case they are informed that the record is locked...and they cannot load it *into* their PC: they only have copies of a record which has been signed out).

If you extend the locking model to indicate where the record exists (i.e. which hub 'has' the record ) your system should be transparent to the user - they are told that the record is locked (because it's on another site).

You have:-

Hub id, location ID, PC id (the later implemented by VFP rlock(), or whatever).

I was suggesting other DBMS's primarily because some have these hub-locks / cross-site locks implemented already (i.e. you wouldn't have to write it yourself).

In VFP you should (!!!) be able to implement it using a primary key value linked to a hub PLUS a value indicating where the record really IS (i.e others are copies).

...if you have a lot of time.

Just my opinion.