HP3000-L Archives

October 1998, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Dirickson Steve <[log in to unmask]>
Reply To:
Dirickson Steve <[log in to unmask]>
Date:
Tue, 6 Oct 1998 15:53:07 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
        <<Okay, I read the version on the LaserROM, but there is one item
that I do not believe was addressed very clearly:  locking. Let's go through
an example.

                user A                          user B
                ------                          ------
                locks search item "A"           locks search item "B"
                dbfind for key "A"              dbfind for key "B"
                reads items in chain            reads items in chain,
                                                   UPDATING "B" to "A"
                                                   in selected records>>


Won't work.

        <<The manual does not state explicitly what needs to be locked. Is
the above scenario possible, or does user B need to lock BOTH keys "B"
(because those are the records being updated) and "A" (because that is the
"new" key) ?>>


Actually, it does-if you can find it. The first sentence under the
"Discussion" topic-head of the DBUPDATE intrinsic (page 5-79 in the 0494
version of the manual, page 5-93 in the 0897 version):
 "Before performing an update for a database opened in access mode 1,
TurboIMAGE/XL verifies that locks are in effect to cover the data entry both
before and after it is modified."

So, in the example, User B would get the usual "no covering lock" error.

Steve

ATOM RSS1 RSS2