>
>
>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.
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only