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