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:
00112724
Vues:
15
Garrett,

I think you don't have much chioce but to use RLOCK().

As I see it, the buffering schemes only move the problem - they don't change the real issue in any way.

So you can RLOCK() at start of things, stopping them from getting any further, *or* you can write the code to try to do the users a favour (since you let them get all the way to the end, not very nice to now wipe out what they have done).

That's my opinion

Cheers,
Jim N

>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....
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform