Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Editing a record - conflict
Message
From
10/11/2006 07:43:13
 
 
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 7 SP1
Miscellaneous
Thread ID:
01168682
Message ID:
01168697
Views:
19
>>>A back to basics question please.
>>>
>>>A table only ever has one record with three fields, dt1, dt2, dt3.
>>>In a multi-user environment, users will update one of these fields.
>>>
>>>Example:
>>>
>>>User 1: changes dt1.
>>>User 2: changes dt2.
>>>
>>>Here is the problem: When user 2 saves the changes to dt2, the changes made by user 1 to dt1 are lost.
>>>
>>>How do I ensure that all changes are accumulative. The last user to update a particular field (say dt3) should stick, but any changes made in the meantime by other users to dt1 or dt2 should not be overwritten when dt3 is saved. How can that be achieved?
>>>
>>>Cyril
>>
>>Is the table buffered and do you use TableUpdate() to commit changes?
>>Are there any rules set up such that the changing of one field resets the other (others), or some such?
>>Would posting your update code not help?
>
>Michel and Terry
>
>Thanks for your comments.
>The table is opened in private data session via the DE of a form. I tried Pessimistic and Optimistic row buffering.
>
>The entire code is just this:
>
>
>select showdate
>locate
>replace dt1 with datetime()
>locate
>
>
>User 2 might do this:
>
>select showdate
>locate
>replace dt2 with datetime()
>locate
>
>
>
>Because user 2 only replaced field dt2, I only want that field in the record to change.
>
>What I don't know is how to refresh the record to have the latest current information for all the fields before the replace is done.
>
>Cyril

Cyril

OK. First of all, if more than one user is likely to edit the record then you could get contention. You should use record locking such as:
select showdate
locate
If RLOCK()
    replace dt1 with datetime()
    = TABLEUPDATE(.T.)
EndIf
locate
Note that, as you're using buffering, you should commit the changes with TABLEUPDATE(.T.).
With optimistic row buffering I understand that moving the file pointer implicitlt does do this. However, as you only have 1 rec in the table, then LOCATE possibly does nothing. Hence your change doesn't get committed.

Whatever, do the right thing and it should all be OK.

Somewhere in the initialisation of the form, in order to use locking, you need to:

Set Multilocks on
Set Reprocess To AUTOMATIC

HTH

Terry
- Whoever said that women are the weaker sex never tried to wrest the bedclothes off one in the middle of the night
- Worry is the interest you pay, in advance, for a loan that you may never need to take out.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform