Re: SQL*Forms4.0 call form

From: Kevin Mallory <kmallory_at_oracle.com>
Date: Tue, 1 Feb 1994 06:07:42 GMT
Message-ID: <KMALLORY.94Jan31220743_at_antfarm.oracle.com>


        For a CALL_FORM()(s) there is fixed amount of PL/SQL context allocated which remains behind when the called form is exited. This is due to the nature of PL/SQL and is not due to the 'convenience' or 'necessity' of Oracle Forms to have this memory around.

        In addition, an application dependant amount of memory *can* be allocated The application dependant amount allocated depends highly on what the 'called' form does in PL/SQL. For example, objects like declarations of exceptions (pragma exeception_init(-020004, MY_EXCEPTION)) cause persistent data to be allocated by PL/SQL which is not released until an entire CALL_FORM chain (i.e. PL/SQL execution context) is exited.

        Off the top of my head, I do not have an exhaustive list of all the PL/SQL builtins which cause memory to be left around in this context, nor do I know the size of the context created by execption_init, or the static PL/SQL context. In the grand scheme of things this is small.

That's the bad news. The good news is that if you are in the scenario of Form A calls Form B, exits back to Form A, then calls Form B again some time later, the memory left behind by Form B for this PL/SQL context is re-used.

What to do: If you have an application heirarch which REQUIRES you to do something like:

Form A calls Form B calls Form C.... Calls Form Z and then you backout to Form A , with NO intention of returning to any of the forms, then you should be using NEW_FORM and passing information via global variables (forms3) or parameter lists (forms4).

--
Kevin Mallory, Oracle Corporation                 
Development Manager, Quality and Performance Programs, Oracle Forms Development

"QUALITY is never an accident; it is always the result of high
intention, sincere effort, intelligent direction and skillful
execution; it represents the wise choice of many alternatives."
Received on Tue Feb 01 1994 - 07:07:42 CET

Original text of this message