Doubts about For each and Find First

Posted by Sidival on 08-Dec-2016 04:33

Is it possible for a "for each" or "find first" to lock an entire table ?


Section 1: For each tt-test where Id_test = 1
Section 2: For each tt-test where id_test = 2

Could someone tell me in which situation an Why one of these programs would show the message "User blocked registry SIN-41"?

All Replies

Posted by cverbiest on 08-Dec-2016 08:06

The message doesn't look like a progress message, definitely not from the sample code you show.

Looking at the names of the buffer I suspect it is a temp-table,

temp-tables cannot be locked, they a private to your session.

if tt-test is a db table and ld_test is not the first segment of an index,

then all records in the table will be share-locked

Posted by Scott Riley on 08-Dec-2016 08:30

As an aside: Attempting to lock temp-table records doesn't give an error and by doing so may future proof your code should Progress decide to introduce locking of temp-tables in the future.

Posted by Stefan Drissen on 08-Dec-2016 14:46

Adding noise that the compiler should not allow (hello strict mode) and may do something (lock the record preventing it from being adjusted by who else exactly?) in the future... no thanks.

Posted by Rutger Olthuis on 08-Dec-2016 15:28

well.. Progress could update the use of no-lock on temp-tables to prevent updating the records yourself. A bit like the final keyword in java.

The problem is that you might want a compiler error and not a runtime error about that...

Posted by cverbiest on 09-Dec-2016 08:42

I agree with Stefan.

We disallow developers to add no-lock to a temp-table find because locking does not exist on temp-tables.

Progress will more likely never do such an update because it could break existing code of some customer.

Posted by bronco on 09-Dec-2016 09:09

I'm with Stefan and Carl. "locking" of temp-tables is conceptually a bit strange. If you need immutability you should come up with a different solution.

Posted by Scott Riley on 09-Dec-2016 09:54

It was just a thought.

One more thing, if you think Progress wouldn't break customers code with an upgrade then you haven't been using Progress for very long - I can think of many but I've been here since V4.

One notable upgrade (think it was 8.1 to 8.2) was the font resizing when nearly every Gui screen had to be adjusted.

Posted by George Potemkin on 09-Dec-2016 10:48

> We disallow developers to add no-lock to a temp-table find because locking does not exist on temp-tables.

What about VSTs? Their locks also do not exist. More over the most of VSTs can't be updated.

I'm using no-lock /and/ exclusive-lock with temp-tables as well as with VSTs. Am I wrong?

Posted by Brian K. Maher on 09-Dec-2016 10:50

That wasn’t us.  That was Windows.

Posted by on 09-Dec-2016 11:46

Don’t worry George, nothing wrong there… certainly not something to be catch by the strict compiler mode, nothing that can confuse the compiler nor other developers seeing it afterwards as it just makes clear your intention.

Not so sure about future-proof claim though, even if PSC will at some point (maybe after we land on Mars or the millennium after that) add some form of multi-threading (maybe inside that multi-session-agent or what ever it’s called) so sharing temp-table(s) data could be an option I expect one need to explicitly define the temp-table as being ‘shared’ so some form of locking can apply, won’t really affect existing code.

Marian Edu

Acorn IT 
+40 740 036 212

Posted by George Potemkin on 09-Dec-2016 12:00

for each tt no-lock:
  assign tt.i = 2.

May be the future Progress versions will rise an error for the code above.

Posted by Scott Riley on 09-Dec-2016 14:10

Strange as when I upgraded from 8.1 to 8.2 Progress we didn't change versions of Windows!?

Here are the facts:

1. Progress knew about the problems the version contained as it had a tool to try to fix the customer's code afterwards.

2. Progress claimed that V8.2 was compatible with Windows when it was released.

Luckily I came across a much better version of the fixing tool written by a Dutch guy which was almost perfect.

Shame Progress couldn't have matched the ability of that one bloke with their version rather than trying to blame the OS.

Some people might say that Progress has a world class DB but the UI was always it's rather ugly, backward, sister - but I wouldn't say this.

Posted by Brian K. Maher on 09-Dec-2016 14:16

If I remember correctly, it was a change of the attributes of the windows default system font related to the new XP 3D look and feel (the height & width of the font changed).  Your version of Windows did not have to change.  When the new version of OE came out that supported it, that meant changes.  Nothing we could really do about it.  We did provide the screen scaling utility to help folks make the jump.

Posted by Tim Kuehn on 10-Dec-2016 10:39

[quote user="cverbiest"]

We disallow developers to add no-lock to a temp-table find because locking does not exist on temp-tables.


I use NO-LOCK / EXCLUSIVE-LOCK on TTs to maintain a consistent coding practice for both DB and TT records and to communicate intent about what the code is intended to do. 

IMO - the more consistent the code base, the fewer "rules" to remember, the better. 

Posted by Alejandro Zbrun on 14-Dec-2016 07:16

Hi Sidival,

That error looks like if you are blocking the register with the first for each. Try to do in this way;

Section 1: For each tt-test where Id_test = 1 no-lock

Section 2: For each tt-test where id_test = 2 no-lock


This thread is closed