Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Really dumb pessimistic buffering Q
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00112690
Message ID:
00112987
Vues:
14
>I have a form that I want to prevent multi-user editing on. I turned pessimistic buffering on and changed the global error handler to throw up a message whenever error 109 came up.
>
>Works fine. If I open it twice, and make an edit to the record in one instance, I get the messagebox in the other instance.
>
>HOWEVER....
>
>If I save the changes in the first instance, and then save the (unmade) changes in the second instance, the second one overwrites the first one. What's the easiest way to deal with this? If I had the time and budget, I'd make it truly multi-user, with CURVAL() and OLDVAL() checking each field, but that isn't really an option.
>
>My next choice is RLOCKing the record when I go into edit mode, but I'd rather work with buffering and implicit locking....
Garrett,

Your pessmistic bufffering is doping an implicit RLOCK() for you. However, once that lock is released by the station that has it, the record is fair game for other stations.

One of my arguments for using and Edit button is that it gives me the opportunity to update the display from disk before the user can Save anything. With automatic editing you need to sense that the user started an edit and then update everything from disk. There is alway the possibility that someone else has changed the data on disk since this user displayed the record. By using an Edit button to allow editing you can have the Save button disabled until the user successfully starts an edit. You can also be sure that the user will see the most current data on disk at the start of their edit.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform