Locked problem on for each

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.

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.

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()

Nice!

I never abused include files. much. well, maybe a little.

now, the guys that originally wrote shell methodology - man, they were include file abusers. Of the worst kind ... that wasn't you, was it ?

Nice!

One of the rare occasions where PSC actually improves the OO language these days.

now, the guys that originally wrote shell methodology - man, they were include file abusers. Of the worst kind ... that wasn't you, was it ? 

I swear not! Tom B. would be LOL if he'd know you'd be suspecting me ever being involved in any shell business. I'm a GUI guy :-)

The 8 include files that I need for the life of me, don't include other include files and all add value to the OO language.

aha! shell methodology *was* gui ... it was smartobjects v0.1 ...

yeah - although a small change, it means that the intellisense doesn't barf in PDS, which does help.