Doubts about For each and Find First - Forum - OpenEdge General - Progress Community

Doubts about For each and Find First


Doubts about For each and Find First

  • 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"?

  • 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

  • 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.

  • 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.

  • 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...

  • 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.

  • 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.

  • 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.

  • > 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?

  • Scott,
    That wasn’t us.  That was Windows.

  • 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

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

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

  • 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.

  • 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.

  • 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.