I'm trying to figure what should I be looking for to make sure that a static temp-table instance goes away.
So I have this;
RUN myproc.p (OUTPUT TABLE ttStatic) ON SERVER myAppServer.
RUN listbuffernames.p () ON SERVER myAppServer. // just scans session buffer handle
For some reason, my listbuffernames.p is listing ttStatic as still available on the appserver. What construct/situation inside myproc.p would cause a static table to remain in the memory after it went out of scope?
I'm trying to figure what should I be looking for to make sure that a static temp-table instance goes away.
So I have this;
RUN myproc.p (OUTPUT TABLE ttStatic) ON SERVER myAppServer.
RUN listbuffernames.p () ON SERVER myAppServer. // just scans session buffer handle
For some reason, my listbuffernames.p is listing ttStatic as still available on the appserver. What construct/situation would cause a static table to remain in the memory after it went out of scope?
Flag this post as spam/abuse.
[quote user="Jeff Ledbetter"]
Jeff LedbetterIs the output parameter on the server-side procedure TABLE or TABLE-HANDLE? If the latter, it must be explicitly deleted.Jeff Ledbetterskype: jeff.ledbetter
Flag this post as spam/abuse.
[quote user="Jeff Ledbetter"]
You can explicitly delete a table- or dataset-handle on the APpServer and be sure that the contents will survive the trip back to the client - there's code that defers the delete until it's been handed back to the client. You can see that in the debugger and the log-mnanager (I believe) where the table is marked as "DELETE PENDING" .
Note that this behaviour is only for returning data across an AppServer boundary and it only works in the .P that was called (ie not further down the stack).
For the rest of the time (ie all other intra-client or intra-server calls) you should be passing references to temp-tables or dataset (to avoid deep copies).
[quote user="Peter Judge"]
You can explicitly delete a table- or dataset-handle on the APpServer and be sure that the contents will survive the trip back to the client - there's code that defers the delete until it's been handed back to the client. You can see that in the debugger and the log-mnanager (I believe) where the table is marked as "DELETE PENDING" .
Note that this behaviour is only for returning data across an AppServer boundary and it only works in the .P that was called (ie not further down the stack).
For the rest of the time (ie all other intra-client or intra-server calls) you should be passing references to temp-tables or dataset (to avoid deep copies).
[/quote]
Just to double check, is this only an issue when passing table handle and not when passing the static temp-table?
Peter JudgeYou can explicitly delete a table- or dataset-handle on the APpServer and be sure that the contents will survive the trip back to the client - there's code that defers the delete until it's been handed back to the client. You can see that in the debugger and the log-mnanager (I believe) where the table is marked as "DELETE PENDING" .Note that this behaviour is only for returning data across an AppServer boundary and it only works in the .P that was called (ie not further down the stack).For the rest of the time (ie all other intra-client or intra-server calls) you should be passing references to temp-tables or dataset (to avoid deep copies).
Just to double check, is this only an issue when passing table handle and not when passing the static temp-table?
Flag this post as spam/abuse.
While diagnosing another mysterious lingering temp-table, I stumble upon this pattern;
ON CHOOSE OF someButton:
DEF VAR hTemp AS HANDLE NO-UNDO.
RUN someprogram.p (OUTPUT TABLE-HANDLE hTemp).
RUN semeprocedure(INPUT TABLE-TANDLE hTemp). /* this internal procedure has code to delete input temp-table handle per earlier discussion, and it works as you stated */
/* However in this scope itself, another copy is created. If I don't do this, a temp-table remains in the memory even after closing this window */
IF VALID-HANDLE(hTemp) THEN
DO:
DELETE OBJECT hTemp.
hTemp = ?.
END.
END.
Maybe the pattern can be pared down. Is this expected?
[EDIT] changed temp-table to table-handle
So we need to clean up sometime in the code if we use something like this?
DEF VAR hTemp AS HANDLE NO-UNDO.
RUN someprogram.p (OUTPUT TABLE-HANDLE hTemp).
My original understanding is that I only need to clean up inside someprogram.p.
Are there any other cases (not just temp-table) where the object creation is implicit and the resulting object is not affected by scoping?
A CATCH Block in 10.1C left oyu in charge with deleting the error object. 10.2A introducted the GC for class based objects to fix that.
Is this only a problem with table-handle and dataset-handle, or is this an issue with handle data-type in general?
Bump. Just trying to make sure if I have to watch out for this behavior when passing widget handle and other types of handles.
Brian,
Can you verify if this behavior affects any handle-type parameter or just temp-table and dataset handle?