>>No, the file does not have to be locked, but the record has.
>>In general it is better not to lock records when people is
>>editing them. The strategy that I use, and that it is recommended
>>by the biggest geeks (regardless of computer, language, or opera
>>tive system) is to put the fields in variables (scatter memvar
>>in FoxPro, or just painstakenly store them one by one) when you
>>"read" the record. Then, when the user hits the key to update,
>>then, and only then you read the record again (without scatter,
>>or without moving your dbf's fields to the variables), RLOCK()
>>the record, move the variables that the user entered to the
>>dbf fields, and finally unlock the record. The advantag of this
>>is that if a user decides to go for lunch in the middle of an
>>editing, you do not have the record locked for everybody else
>>for 2 hours (we take long lunchs around here).
>Ok Give me a solid way to check if the record is not changed in the
>meanwhile? What do you let the User do if the record is changed?
Assuming that you know that the record has been changed, the classic
technique is to offer the user the choice of cancelling his changes
and accepting the new version and canceling his changes or of overwriting
with his own new version of the record. You can check for a
changed record by scattering the record to an array when you first
pick up the record for amendment. Then, just before you commit the
users updates, check the record in the file to see it has changed
(field by field comparison with your saved snapshot of the record).
There is a snag here. The change that has occured could have been
an essential change (decided as essential by someone else) or a flag
set by some sort of system process). In any case you would not want
a junior user who is changing a clients telephone number overwriting
a new credit limit set by the boss.
You can minimise the problem dramatically. In reality, if there is a
collision of changes - a record has been changed in two places in the
same time span - the collision occurs at record level not at field level.
In other words, two people might be changing data in a record at the
same time but rarely are both changing the client telephone number at
the same time. The solution is to be a bit cunning while you are
checking the record for change collision. Say user A has changed a
field or two while user B is entering his or her changes. Before
commiting B's version of the record, lock the record, check field by
field. If a field has been changed by A but not by B then accept A's
version and overwrite B's old version. If a field has been changed
by B and not by A then of course accept B's version. If a field has
been changed by both (change collision) then dump all changes by B
*AND* inform B that what has happened. I have found this method works
well in practice for all versions of foxpro.
Hope that made sense Willy :-)