Something I got used to in other languages is using Find Current to change lock status while in a loop (For Each)
I think it is much cleaner to change the lock status for this one record and then update and release record, rather than having to define a 2nd buffer, finding the same record in 2nd buffer with exclusive lock and update it.
I would like to be able to do something like this:
FOR EACH Customer NO-LOCK:
<do logic checks>
FIND CURRENT Customer EXCLUSIVE-LOCK.
<do updates>
RELEASE Customer.
END.
DEFINE BUFFER lb-Customer for customer.
FOR EACH Customer NO-LOCK:
<do logic checks>
do for lb-customer transaction:
FIND lb-Customer EXCLUSIVE-LOCK where rowid(lb-customer) eq rowid(customer) no-error.
<do updates>
end.
END.
No need to release. It doesn't do what you think it does.
The problem with your code is that even if you could do that it would make the transaction scope wrong and you'd have all sorts of problems.
James thanks for that, but I only put the code in as an example :) I know what Release and Validate does and understand buffers and know that this is how progress currently works. But it was not a question on how it is currently done within progress, more a discussion on merits of not having to create a 2nd buffer and then do find on a record you already have in a buffer. A lot of other languages i have worked in allow you to just change the lock status of the record you are busy with, without influencing the outer loop, hence the reason I put the release which in other languages also down grades locks. So my code example was more of how I would like it to work, not how it works. It saves on data base retrievals, saves on memory, ...
RELEASE - Verifies that a record complies with mandatory field and unique index definitions. It clears the record from the buffer and unites it to the database if it has been changed.
VALIDATE - Verifies that a record complies with mandatory field and unique index definitions.
Ah sorry I misread your post. *oops*
I'm not sure I'd want what you propose. I think it would muddy the waters in terms of transaction scoping, and would make code inherently less easy to read as you don't see straight away if a buffer is being updated or not.
Sorry, but I don’t understand what you’re asking for. You certainly CAN use FIND CURRENT on the existing FOR EACH buffer. Though of course the lock will be held till the end of the transaction. So you could do this:
FOR EACH Customer NO-LOCK:
DO TRANSACTION:
FIND CURRENT Customer EXCLUSIVE-LOCK.
<do updates>
RELEASE Customer.
END.
/* Here the lock is released. */
/* Without the RELEASE, the lock will be downgraded to a SHARE-LOCK. */
END.
So what’s the issue?
Laura - your example is a bit puzzling as I recall running into situations where trying to change a buffer's lock resulted in a compiler complaint about changing the lock status of a query.
Has this been changed in a recent release?
I just ran this code and it ran fine. I don't think it's been changed but couldn't swear to that.
Did you mean compiler complaint or runtime?
Reply by Laura SternI just ran this code and it ran fine. I don't think it's been changed but couldn't swear to that.
Did you mean compiler complaint or runtime?
Stop receiving emails on this subject.Flag this post as spam/abuse.
-- Tom Bascom 603 396 4886 tom@greenfieldtech.com[/collapse]
As I recall, I got a compiler complaint.
I wrote similar code on my 11.5 W7/64 and it compiled.
Reply by Alex HartJames thanks for that, but I only put the code in as an example :) I know what Release and Validate does and understand buffers and know that this is how progress currently works. But it was not a question on how it is currently done within progress, more a discussion on merits of not having to create a 2nd buffer and then do find on a record you already have in a buffer. A lot of other languages i have worked in allow you to just change the lock status of the record you are busy with, without influencing the outer loop, hence the reason I put the release which in other languages also down grades locks. So my code example was more of how I would like it to work, not how it works. It saves on data base retrievals, saves on memory, ...
RELEASE - Verifies that a record complies with mandatory field and unique index definitions. It clears the record from the buffer and unites it to the database if it has been changed.
VALIDATE - Verifies that a record complies with mandatory field and unique index definitions.
Stop receiving emails on this subject.Flag this post as spam/abuse.
-- Tom Bascom 603 396 4886 tom@greenfieldtech.com[/collapse]
The problem with your code is that even if you could do that it would make the transaction scope wrong and you'd have all sorts of problems.
Flag this post as spam/abuse.
Apologies Tom. lb- is a bad habit that's hard to break. It's part of our "coding standards".
Ah.. Indeed. This was fixed in 11.4. You will still get this error if you do a "normal" FIND. But you will no longer get the error with FIND CURRENT.
That last post was of course referring to error: FIND cannot be processed for a FOR EACH mode record. (213)
James, just because Tom wants to rant about what his ideas are for good
naming doesn't mean that you need to apologize for having different
idea. Many of us do and have good reasons for why we think that way.
Reply by Thomas Mercer-HurshJames, just because Tom wants to rant about what his ideas are for good
naming doesn't mean that you need to apologize for having different
idea. Many of us do and have good reasons for why we think that way.Stop receiving emails on this subject.Flag this post as spam/abuse.
-- Tom Bascom 603 396 4886 tom@greenfieldtech.com