Effect on Permanent Objects
Documentation | Blog | Demos | Support
Effect on Permanent Objects
0 out of 5 stars
5 Stars | 0% | |
4 Stars | 0% | |
3 Stars | 0% | |
2 Stars | 0% | |
1 Stars | 0% |
In the context of compiled programs, the term permanent object refers to any object that, once created in the application database (based on a definition in the Object Dictionary), persists until erased. Permanent objects include EntitySets, relationships, roles, application documents, application directories, windows, menus, displays, forms, constants, variables, and permanent result sets (set objects).
Application programs are compiled in the context of the permanent objects that are available at the time of compilation; that is, all objects in the application directories that are accessed at the time that the COMPILE command is executed.
Within the program being compiled, ACCESS or RELEASE commands – which affect the application directories that are available, and, by extension, the permanent objects that are available – are ignored.
References to permanent objects are compiled into explicit references to specific objects in specific application directories. As a result, at execution time, the compiled program is independent of the currently accessed directories; all permanent object references have already been resolved.
One exception to this rule occurs when a compiled program calls another program. Zim seeks the called program in the currently accessed application directories. If the software finds the called program there, it determines if the program has been compiled and executes the compiled or source version accordingly. If the software fails to find the called program within the currently accessed application directories, it attempts to execute the compiled version of the called program (if a compiled version exists).
0 out of 5 stars
5 Stars | 0% | |
4 Stars | 0% | |
3 Stars | 0% | |
2 Stars | 0% | |
1 Stars | 0% |