Kbase P21924: What is the difference between persistent and non persistent procedures
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/16/2008 |
|
Status: Verified
GOAL:
What is the difference between persistent and non persistent procedures
FIX:
A non-persistent procedure creates and maintains its context only until it returns from execution.
The context of a non-persistent procedure remains in scope only until the RUN statement that executes it completes.
A persistent procedure creates its context when it executes and then maintains that context after it returns until the end of the Progress session, or until it is explicitly deleted.
The context of a persistent procedure remains in scope after the RUN statement that executes it completes until you remove it. As long as its context is in scope, the triggers and internal procedures of a persistent procedure remain available for execution by your application.
NOTE: If you run an application that creates persistent procedures from an ADE tool, that tool (for example, the Procedure Editor or User Interface Builder) removes all instances of persistent procedures still created when the application terminates.
Advantages of Persistent Procedures:
Persistent procedures promote modular application design and development by more easily allowing you to distribute functionality among several procedures. For example, you might build a persistent procedure that provides access to a database through a set of local buffers that it otherwise hides from the rest of the application. Or your persistent procedure might create and manage its own windows while allowing independent access (non-modal access) to other windows in your application. Aside from helping to manage functionality, the additional modularity also helps to avoid hitting r-code segment limits.
Thus, creating a persistent procedure whose context you access through internal procedures provides the most effective means to achieve encapsulation in Progress. For more information on using internal procedures to promote encapsulation, see the "Internal Procedures" section.
You can also use a persistent procedure to create multiple versions of the same context. Each time you call a persistent procedure, it creates a separate instance of its context. Your application (and user) can access and manage each context independently from the others. If your persistent procedure manages its own windows, you can use this feature to provide some (but not all) of the capabilities of the Microsoft multiple document interface (MDI).