Inconsistent behavior: Buffer availability with FINALLY blocks - Forum - OpenEdge Development - Progress Community

Inconsistent behavior: Buffer availability with FINALLY blocks

 Forum

Inconsistent behavior: Buffer availability with FINALLY blocks

This question is answered

I have noticed a behavior inconsistency with regards to buffer availability and FINALLY blocks. I made sure that I executed the exact same code in the different environments.

Here is the simplified program to demonstrate:

DEFINE TEMP-TABLE ttTest  NO-UNDO
  FIELD cField  AS CHARACTER INITIAL "123".

DEFINE BUFFER bufTest FOR ttTest.

CREATE bufTest.

MESSAGE
    "SESSION:DISPLAY-TYPE:" SESSION:DISPLAY-TYPE SKIP
    "SESSION:CLIENT-TYPE:"  SESSION:CLIENT-TYPE  SKIP
    "PROVERSION(1):"      PROVERSION(1)        SKIP
    "AVAILABLE bufTest:"  AVAILABLE bufTest
  VIEW-AS ALERT-BOX INFO BUTTONS OK.

FINALLY:
  MESSAGE
      "AVAILABLE bufTest:" AVAILABLE bufTest
    VIEW-AS ALERT-BOX INFO BUTTONS OK.
END FINALLY.

In an Windows AppBuilder, these are the messages I get:

  First message

SESSION:DISPLAY-TYPE: GUI
SESSION:CLIENT-TYPE: 4GLCLIENT
PROVERSION(1): 11.7.5.0.1811
AVAILABLE bufTest: yes

  Second message

AVAILABLE bufTest: no

In an Linux mpro editor, these are the messages I get:

  First message

SESSION:DISPLAY-TYPE: TTY
SESSION:CLIENT-TYPE: 4GLCLIENT
PROVERSION(1): 11.7.5.0.1811
AVAILABLE bufTest: yes

  Second message

AVAILABLE bufTest: no

In a Classic WebSpeed environment, these are the messages I get:

  First message

SESSION:DISPLAY-TYPE: TTY
SESSION:CLIENT-TYPE: WEBSPEED
PROVERSION(1): 11.7.5.0.1811
AVAILABLE bufTest: yes

  Second message

AVAILABLE bufTest: yes

Notice that the message in the FINALLY block on Classic WebSpeed is yes, while the others are no. What is interesting, is that the Classic WebSpeed and Linux mpro editor messages are from the same machine. The problem is that we have existing code that works according to the Classic WebSpeed behavior.

I noticed the inconsistency when some of our programs stopped working when I evaluated PASOE on OE 12.0 and OE 12.1 - which also reports no in the FINALLY block.

Question is, what is the correct behavior? For us, it is a change in behavior, and it might be difficult to identify other pieces of code in the system that follows the same pattern.

Verified Answer
  • But according to Tim Sargent:  Unless it’s run as a persistent procedure (which I’ll bet classic webspeed is). If it’s run persistent, any buffers scoped to the main .p are not disconnected until the procedure is deleted.

    You could experiment with this outside of WebSpeed to verify.

All Replies
  • I would consider this to be a bug.  Please open a case with support so we can look into it.

  • Since I assume this is showing the entire .p, the answer should be No.  The record is released at the end of the record scope, which is the .p in this case.  End of block processing, such as buffer releases or any undo, happens before the finally block runs.  

    Yes, it is a bug.  The behavior should be the same in all AVM contexts.

  • But according to Tim Sargent:  Unless it’s run as a persistent procedure (which I’ll bet classic webspeed is). If it’s run persistent, any buffers scoped to the main .p are not disconnected until the procedure is deleted.

    You could experiment with this outside of WebSpeed to verify.

  • All of which reinforces the importance of always scoping a buffer to a block.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • We always scope our buffers. In this case, the buffer was meant to be scoped to the procedure for efficiency sake.

    Behavior is different with persistence, as Tim suggested. The only weirdness here is that WebSpeed behaves differently - and from what I could see, run-web-object in web-util.p does not run programs persistently.

    Thanks for the feedback. I go the answer I needed. I doubt we'll have more programs that fall into this category, especially taking persistence into consideration. We'll only know when we hit it somewhere else. You can't identify this with XREF or LISTING compiles, which means it would be difficult to try and be proactive.