Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Multiuser Misery
Message
De
22/07/2001 19:17:54
Nancy Folsom
Pixel Dust Industries
Washington, États-Unis
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00533710
Message ID:
00533715
Vues:
14
>I am converting a simple single user application to multiuser for the first time.
>Assume that I have a simple form that updates a table containing one record.
>I have done the following:
> set exclusive off
> buffermode=pessimistic
> windowtype=modeless
> datasession=private datasession
> the form has a commandbutton with code in the click event as follows:
> tableupdate()
>my application consists of the form and a program containing this code:
> do myform
> read events
>
>I build the project into an .exe which works fine.
>
>Then I run two instances of the .exe
>I change a field in the record on one instance, without updating. Then I attempt to change a field in the second instance. I get a message "attempting to lock... press ESC to cancel". I press escape and get a message "Record is in use by another user". The choices are Cancel, Ignore and Help. I choose Ignore. But the program terminates! Why is this? I want the attempted change to fail and make the user to wait until the record is available and try again. [If I trap the error and put in my own error message the same thing happens. I have a much more complicated version of this application and this one works correctly the first time, but the second time the user attempts to change a locked record, the program terminates.]

Hi, Jay-

Do you really _want_ pessimistic locking? It sounds to me like you want optimistic Locking instead. Then you don't have to worry about collisions til you do your TABLEUPDATE(). You can use GetFldState() to check on whether any fields have been changed or not, and if so, what,if anything, to do about it. (You can choose a number of options.)

Consider reading Booth and Sawyer's suggestions for how to manage this in Effective Techniques which is available from www.hentzenwerke.com. I think their suggestions for this are lucid, plain, and practical.

In the case that bombs I'm not sure, but perhaps your trapping code does something that really crashes your code. You'd need to tell us what line of code causes the crash and what the error message is.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform