Mike Castle wrote:
>On Thu, Aug 23, 2001 at 10:09:19AM -0400, Jan Wieck wrote:
>> Oliver Elphick wrote:
>> > I can see arguments to support this view, but consider this classic
>> > scenario:
>> >
>> > User1: Read data into an interactive program
>> > User1: Start to make changes
>> > User2: Read data into an interactive program
>> > User2: Start to make changes
>> > User1: Save changes
>> > User2: Save changes
>
>Consider replacing "Save changes" with:
>
>User1: Lock record, compare original with current record, save if same, unlo
>ck
>User2: Lock record, compare original with current record, notice difference,
> abort.
Yes, but if User2 has done substantial editing changes to a field (after all
we could store whole books in a SQL field now), his changes will be rejected
and the program will have to throw them away or else try to integrate them
with the new field contents - in either case there is substantial wasted
effort.
I prefer Jan's solution: on first attempt to change, acquire a user-level
lock by creating a lock record; if you can't get the lock, don't allow
any change.
However, it would be convenient if the database would do this for me. I
still don't understand why people think it undesirable for it to do so, since
it is a problem universal to multi-user databases and the effort is
therefore more economically spent at the database rather than at the
application level.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"For God hath not appointed us to wrath, but to obtain
salvation by our Lord Jesus Christ, Who died for us,
that, whether we wake or sleep, we should live
together with him."
I Thessalonians 5:9,10
