|Oracle® OLAP DML Reference
11g Release 1 (11.1)
|PDF · Mobi · ePub|
The COMPILE command generates compiled code for a compilable object, such as a program, formula, model, or aggmap without running it and saves the compiled code in the analytic workspace. During compilation, COMPILE checks for format errors, so you can use COMPILE to help debug your code before running it. COMPILE records the errors in the current outfile.
However, you are not required to use the COMPILE command before running a compilable object. When you do not use COMPILE, Oracle OLAP automatically compiles a compilable object the first time you run it after entering or changing its contents. This automatic compilation is unnoticeable except for a slight delay while it is happening. Use the OBJ function with the ISCOMPILED keyword to obtain information about the compilation status of a compilable object.
Whether you compile an object explicitly with COMPILE or automatically through running it, the code executes faster whenever you subsequently run the object during the same session, because the code is already compiled. When you update and commit your analytic workspace, the compiled code is saved as part of your analytic workspace and can be used in later sessions. The code thus executes faster the first time it is run in each later session.
Using COMPILE to compile code without running a compilable object is especially useful when you are writing code that will be part of a read-only analytic workspace (that is, a analytic workspace that people can use but not update).
The name of a compilable object that you want to compile.
A number of options effect compilation. These options are listed in "Compilation Options". By setting one or more of these options you can suppress error messages that appear at compilation time or replace occurrences of
THIS_AW with a specified value.
When you delete or rename an object in your analytic workspace, Oracle OLAP automatically invalidates the compiled code for every statement in a program and every formula and model that depends on that object. When you try to execute code that refers to the deleted or renamed object, Oracle OLAP tries to compile the code again. Unless you have defined a new object with the same name, you will receive an error message at this time.
When you run a program that contains invalidated code, it is compiled and executed one statement at a time. To save compiled code for the entire program, use the COMPILE command to explicitly compile it.
When a single statement has more than one error, COMPILE finds only the first error. However, COMPILE continues checking for format errors in subsequent statements.
COMPILE handles declarative errors differently in programs and models:
When a program has a declarative error (for example, when a VARIABLE or ARG statement follows executable code), COMPILE signals a trappable error
When a model has a declarative model (for example, when a model statement has a DIMENSION statement following an assignment statement) COMPILE does not signal a trappable error. Instead, the model is not executable.
See the TRAP command for more information on trapping error.s
Explicit compilation using the COMPILE command offers several advantages over automatic compilation:
For any compilable object, COMPILE generates compiled code without executing the code in the object.
In a program or model, automatic compilation diagnoses an error only in the first statement that contains an error. It then displays the error message and halts the execution of a program or the analysis of a model. So each time a program or model is automatically compiled, only a single error message is displayed. In contrast, COMPILE checks every statement in a program or model for correct format, and generates multiple error messages, one for each statement that contains an error. (In programs, some types of statements cannot be compiled, so they are exceptions. See "Errors COMPILE Does Not Catch".) Since COMPILE shows you every statement that contains at least one error, this minimizes the number of times you must edit the code to correct all errors.
For a model, you may want to examine the results of the compilation or set options for handling simultaneous equations before you run the model.
Because the COMPILE command does not actually execute code, it can compile code that, for reasons unrelated to format errors, might not be successfully executed when the object were actually run. In a program, for example, you can compile the following statement, even though 'joplin' is not a district.
LIMIT district TO 'joplin'
Although the statement compiles successfully, you will get an error message at runtime.
In programs, certain statements cannot be compiled at all, and are therefore interpreted each time they are executed. These include statements that contain ampersand substitution, statements involving analytic workspace operations, and any statement that calls a program as a command. (Statements that call a program as a function or with the CALL command are compiled.)
You can use the PRGTRACE option to check which statements in a program have been compiled. When you set PRGTRACE to
YES and run a program, each statement is recorded in the current outfile before it is executed. A compiled statement is identified with an equal sign.
(PRG= program-name) statement
An uncompiled statement is identified with a colon.
(PRG: program-name) statement
When you compile a compilable object that uses objects in another analytic workspace, the second analytic workspace must be attached to your current Oracle OLAP session. You can then run the compilable object with that analytic workspace or another analytic workspace with objects of the same name and type attached. Oracle OLAP checks that the objects have the same name, type (variable, dimension, and so on), data type (
TEXT, and so on), and dimensions as the objects used to compile the compilable object.
When you have more than one active analytic workspace, do not have objects of the same name in both analytic workspaces. For example, when you have an analytic workspace of programs and two analytic workspaces with data about the products Tea and Coffee, both product analytic workspaces can have a MONTH dimension and the programs can refer to MONTH. However, during your session, attach only one product analytic workspace at a time so that there is only one MONTH dimension.
In order for code to compile, all variables referenced in a program (with the exception of variables in lines containing ampersand substitution) must be loaded into memory. This means Oracle OLAP reads the definition of every variable you use and stores it in a portion of available memory that is dedicated for storing object definitions. When the compilation tries to bind a large variable, this may use a large amount of memory and create a large
EXPTEMP file. When the compilation tries to bind a large number of large variables, it may fail and Oracle OLAP will record an error message such as 'Insufficient Main Memory'. See the LOAD command for more information about loading an object's definition into memory.
Suppose you misspell the dimension
month in a LIMIT command in the
LIMIT motnh TO LAST 6
COMPILE command encounters this statement, it produces the following message.
ERROR: (MXMSERR00) Analytic workspace object MOTNH does not exist. In DEMO!MYPROG PROGRAM: limit month to last 6
You can edit the program to correct the error and then try to compile it again.
This example shows a program called
salesrpt that contains two errors.
DEFINE salesrpt PROGRAM PROGRAM ROW WIDTH 80 CENTER Monthly Report BLANK 2 ROWW 'Total Sales' TOTAL(sales) END
You can compile the program with the following statement.
Oracle OLAP identifies both errors and records the following messages.
ERROR: You provided extra input starting at 'REPORT'. In SALESRPT PROGRAM: ROW WIDTH 80 CENTER Monthly Report ERROR: ROWW is not a command. In SALESRPT PROGRAM: roww 'Total Sales' TOTAL(sales)
You can now edit the program to correct these errors, enclosing
'Monthly Report' in single quotes and correcting the spelling of
ROWW. Then you can compile the program again, and save the compiled code as part of your analytic workspace.