Locked problem on for each - Forum - OpenEdge General - Progress Community

Locked problem on for each

 Forum

Locked problem on for each

  • How can I test a lock on a for each?

    for exemple:

    for each customer:

         if locked(customer)

         then do:

              message "Register is in use by other user".

              undo.

         end.

    end.

    It doesn't works...

    How can I test this lock?

    Thanks for helping.

  • try this:

    for each customer no-lock:

    buffer customer:find-current(exclusive,no-wait) no-error.

    if error-status:num-messages gt 0 then /** could not get lock, so

    must be locked elsewhere */

  • Look at the NO-WAIT keyword. It doesn't work on the FOR EACH statement, just on FIND.

    You'd have to do something like the following - changes in CAPS. The doc suggests you can use any lock status with NO-WAIT but you need to use SHARE- or EXCLUSIVE-LOCK.

    DEFINE BUFFER lbCustomer FOR CUSTOMER.

    for each customer NO-LOCK:

    /* this find is about as fast as it gets in ABL */

    FIND lbCustomer WHERE

    ROWID(lbCustomer) EQ ROWID(Customer)

    EXCLUSIVE-LOCK NO-WAIT NO-ERROR.

    if locked(lbCustomer)

    then do:

    message "Register is in use by other user".

    undo.

    end.

    end.

    -- peter

  • fyi, the doc is correct, though perhaps a little misleading. you can use any lock status. NO-LOCK is the absence of a lock and a lock that does not exist cannot have a status.

  • Thanks for replying, Julian.

    Unfortunately I couldn't make it works.

    This was my test:

    at first I did it in one terminal.

    find first customer exclusive-lock.

    pause.

    after, I've typed your code, and all register have appeared.

    I've tried others forms, and nothing works...

  • Hey, Peter. Thaks.

    it really works!

    Actually, I've tried it already... but it's not the kind of thing that i'm looking for...

    I would like to test this lock without access the same register with a buffer and a find.

    I'm hopeful to find some function that does it for me.

    Thanks for help, anyway.
  • oops. I just typed some pseudo-code.

    try this :

    for each client no-lock transaction:

      buffer client:find-current(exclusive,no-wait) .

      if buffer client:locked then message "oops" view-as alert-box.

    it seems to work for me. At least, I get the "oops" message when a record is locked in another session

    HTH

  • Thanks, Man!

    It worked perfectly!

  • good news.

  • I'm hopeful to find some function that does it for me.

    >

    Unfortunately, that's it (Julian's solution is basically the same thing, just fooling the compiler a little :).

    You do want to be careful about iterating over large number of records with a share- or exclusive-lock, so doing a re-find may be a good solution anyway.

    I think that the language needs an equivalent to NO-WAIT for FOR blocks. I would suggest contacting tech support about this.

    Incidentally, that message you see is not catchable via structured error handling, even though it's not a STOP. It's apparently an old, old construct that lives by its own rules (paraphrasing somewhat).

    Something like the below might be nice in the future.

    FOR EACH Customer EXCLUSIVE-LOCK

    ON LOCKED UNDO, NEXT

    CATCH e AS Progress.Lang.Error:

    If e:GetMessage(1) EQ 0000 THEN MESSAGE 'locked, not loaded!'

    END CATCH.

    END.

    -- peter

  • Hey, Peter!

    You're absolute right.

    I've tought a little about the code, and I realized this code is the same of your example.

    A no-wait clause with a locked function on for could be a good thing, on the same way on that works on find.

    Thanks for help.

  • "Julian's solution is basically the same thing, just fooling the compiler a little :"

    bad, bad compiler for allowing such tricks to be played on it

  • bad, bad compiler for allowing such tricks to be played on it

     

    Says the guy who abused Include files so badly in the past, that he hates them like the pest today?

  • I know you also like the

    (new Foo()):someMethod()

    trick

  • pjudge wrote:

    I know you also like the

       (new Foo()):someMethod()

    trick

    Yup! I've banged on so much about it, it has been fixed in 11.3

    new Foo():someMethod()