Charles: I'm thinking of instead of a:
READVU SeqNo FROM FILENAME.FV, 'CTRL', 1 ELSE SeqNo = 0 . ...test for existence and get the next unique value ...update record WRITEV SeqNo ON FILENAME.FV, 'CTRL', 1 do something like: LOCK 50 READV SeqNo FROM FILENAME.FV, 'CTRL', 1 ELSE SeqNo = 0 . ...test for existence and get the next unique value ...update record WRITEV SeqNo ON FILENAME.FV, 'CTRL', 1 UNLOCK 50 Then make sure this is either an include or a subroutine used by everything that needs a particular unique sequence no. In this case, everyone gets the momentary lock they need and transaction bracketing doesn't break the locking mechanism. Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Stevenson, Charles > Sent: Wednesday, June 15, 2005 8:55 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Best practice for Sequential IDs using > TRANSACTION START & COMMIT/R... > > From: Bill Haskett > > I wonder if the same issue (transactions don't release record locks > > until they're committed) applies to the LOCK/UNLOCK statement? > > No, those are independent of transactions. > So could they be leveraged for the question posed here? > . . . I don't see it. > > cds > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
