Defines a temp-table that is created at compile time. The AVM stores temp-tables in memory (with potential overflow to disk). Among procedures, a temp-table can be either global (lasting for the entire ABL session) or local (lasting only as long as the procedure that creates it), and either shared (visible to other procedures that want to access it) or non-shared (visible just to the procedure that created it). In a class, a temp-table can be defined for use within a single class or class hierarchy.
DEFINE {[[ NEW [ GLOBAL ]] SHARED ]|
[ PRIVATE | PROTECTED ][ STATIC ]
[ SERIALIZABLE | NON-SERIALIZABLE ]}
TEMP-TABLE temp-table-name[ NO-UNDO ]
[ NAMESPACE-URI namespace][ NAMESPACE-PREFIX prefix]
[ XML-NODE-NAME node-name][ SERIALIZE-NAME serialize-name ]
[ REFERENCE-ONLY ]
[ LIKE table-name
[ VALIDATE ]
[ USE-INDEX index-name[ AS PRIMARY ]]...]
[ LIKE-SEQUENTIAL table-name
[ VALIDATE ]
[ USE-INDEX index-name[ AS PRIMARY ]]...]
[ RCODE-INFORMATION ]
[ BEFORE-TABLE before-table-name]
[ FIELD field-name
{ AS data-type| LIKE field[ VALIDATE ]}
[field-options]
]...
[ INDEX index-name
[[ AS | IS ][ UNIQUE ][ PRIMARY ][ WORD-INDEX ]]
{index-field[ ASCENDING | DESCENDING ]}...
]...
|
The procedure that establishes the temp-table determines the name. The procedures that share the temp-table use that name to identify it.
A temp-table defined with the STATIC option is a static data member of the class type for which it is defined, and it is scoped to the ABL session where it is referenced. ABL creates one copy of the specified class static temp-table at the first reference to the class type, and creates only one such copy for any number of instances of the class that you create. You cannot specify STATIC if you specify the REFERENCE-ONLY option. You can directly reference an accessible static temp-table data member from any other static or instance class member defined in the same class or class hierarchy.
Without the STATIC option, ABL creates an instance temp-table data member that is scoped to a single instance of the class where it is defined. ABL creates one copy of the specified instance temp-table for each such class instance that you create. You cannot directly reference an instance temp-table data member from a STATIC class member definition defined within the same class or class hierarchy.
For more information on accessing temp-tables of different access modes and scopes, see the reference entry for Class-based data member access.
Class-based objects that are defined as serializable (using the SERIALIZABLE option in the CLASS statement) can be passed as parameters in remotes call between the AppServer and ABL clients and can be serialized to binary or JSON format. By default, both passing a class as a parameter and serializing an object to binary via the Progress.IO.BinarySerializer class include all data members regardless of access mode. However, for JSON serialization via Progress.IO.JsonSerializer, only public data members are serialized. To include a protected or private property during JSON serialization, SERIALIZABLE must be added to the definition. See Serialize( ) method (JsonSerializer) for more information.Use the NON-SERIALIZABLE option to exclude a given temp-table from parameter passing between an AppServer and ABL client and from the serialization process via the Progress.IO.BinarySerializer class. (Temp-tables are NON-SERIALIZABLE by default via the Progress.IO.JsonSerializer class because they cannot be defined as public.) Fields of a temp-table marked as NON-SERIALIZABLE revert to their initial values when the class is deserialized.
For more information on where and how to define data members in a class, see the CLASS statement reference entry.
Passing a reference-only temp-table object parameter to a local routine using either the BY-REFERENCE or BIND option allows the calling routine and the called routine to access the same object instance (instead of deep-copying the parameter).
When you pass a temp-table parameter to a local routine using the BY-REFERENCE option, both the calling and called routines access the calling routine's object instance (and ignore the called routine's object instance). Since the called routine's object instance is ignored, you should define the object as a reference-only object. When you define a reference-only temp-table object in the called routine and receive it from the calling routine using the BY-REFERENCE option, the AVM binds the definition of the object in the called routine to the object instance in the calling routine for the duration of the called routine. You cannot define a reference-only temp-table object in the calling routine and pass it to the called routine using the BY-REFERENCE option.
When you pass a temp-table parameter to a local routine using the BIND option, you can define a reference-only temp-table object in either the calling routine or the called routine as follows:
In either case, you must specify the BIND option for the parameter in both the invocation of a RUN statement, a method in a class, or a user-defined function, and in the DEFINE PARAMETER statement.
A reference-only temp-table object can be a member of a reference-only ProDataSet object or a standard ProDataSet object. However, if you define a reference-only temp-table in a standard ProDataSet object, you cannot use the ProDataSet object until you bind the reference-only temp-table.
If you reference a database field, the database containing that field must be connected at compile time. If the database field has a validation expression defined in the dictionary that contains a database reference, and the VALIDATE option is specified, the database must also be connected at run-time.
HELP options are inherited from the table-name. Validate options are inherited only if the VALIDATE keyword is used.
Some index definitions from the specified table might also be added to the temp-table:
For example, to make the index country-post the primary index (thereby, overriding the default primary index CustNum in the table Customer), you specify it as follows:
LIKE-SEQUENTIAL is similar to LIKE in all ways except one. Unlike LIKE, which creates temp-table fields in _field._field-rpos order (POSITION order in the .df schema definition file) of the source table's fields, LIKE-SEQUENTIAL creates fields in _field._order sequence.
You can guarantee agreement of temp-table field order between any client and any AppServer using LIKE-SEQUENTIAL, as long as the _field._order values are the same. LIKE-SEQUENTIAL uses the field order as defined in the Data Dictionary when the source is a database table.
For more information on these data types, see the Data types reference entry.
For the CLASS data type, you define a field in a temp-table as a class by specifying the built-in Progress.Lang.Object class name. For example:
When you assign a class instance to a field, ABL implicitly casts the instance to its root super class, which is the Progress.Lang.Object class. After the assignment, the field contains an object reference to the class instance, not the object itself.
You cannot define a field in a database table as a class.
If the database field is a COLUMN-CODEPAGE CLOB, the temp-table field is in the database field's code page. If the database field is a DBCODEPAGE CLOB, the temp-table field's code page is -cpinternal.
You can override selected characteristics of the field or variable with the field-options parameter.
If you reference a database field in the LIKE option, the database containing that field must be connected at both compile time and run time. Therefore, use the LIKE option with caution.
{
[ BGCOLOR expression]
[ COLUMN-LABEL label]
[ DCOLOR expression]
[ DECIMALS n]
[ EXTENT n]
[ FONT expression]
[ FGCOLOR expression]
[ FORMAT string]
[ HELP help-text]
[ INITIAL
{constant|{ [ constant[ , constant]... ] }}
]
[ LABEL label[ , label]...]
[ MOUSE-POINTER expression]
[[ NOT ] CASE-SENSITIVE ]
[ PFCOLOR expression]
[ SERIALIZE-HIDDEN ]
[ SERIALIZE-NAME serialize-name ]
[ TTCODEPAGE | COLUMN-CODEPAGE codepage]
[ XML-DATA-TYPE string]
[ XML-NODE-TYPE string]
[ XML-NODE-NAME node-name]
{[view-as-phrase]}
}
|
If you do not specify a code page for a CLOB field in the temp-table, the default code page is -cpinternal.
For more information about the ABL XML data type mapping rules, see OpenEdge Development: Working with XML.
The following table lists the valid XML node types.
| When the XML node type is . . . | The buffer field is . . . |
|---|---|
| ATTRIBUTE | Represented as an attribute of the temp-table element in both the XML Schema and data. |
| ELEMENT | Represented as a child element of the temp-table element in both the XML schema and data. |
| HIDDEN | Omitted from both the XML Schema and data. |
| TEXT | Represented as a text element in both the XML Schema and
data. Note: Each table can contain only one TEXT field. When a
table contains a TEXT field, it cannot contain ELEMENT fields; it can
contain only ATTRIBUTE fields. A table that contains a TEXT field cannot be
part of a nested data-relation.
|
The XML node type of a temp-table field that represents an array must be either "ELEMENT" or "HIDDEN".
For more information and a description of all other field options, see the DEFINE VARIABLE statement.
If you define more than one index on the temp-table, you can specify PRIMARY for none or one of the indexes. If you specify PRIMARY for none of the indexes, the AVM makes the first index you specify the primary index.
If you define no indexes on the temp-table, and the temp-table does not inherit the indexes of another table through the LIKE option of the DEFINE TEMP-TABLE statement, the AVM creates a default index, makes it the primary index, and sorts the records in entry order. If you do not specify the USE-INDEX option under LIKE but do use the INDEX option, then no indexes are copied from the specified table unless the specified table is another temp-table.
If you do not specify a sort orientation (ASCENDING or DESCENDING), the index component gets the sort orientation of the previous index component, or, if there is no previous index component, ASCENDING. This rule applies only to index components of temp-tables.
For example, the following two temp-table definitions are equivalent:
DEFINE TEMP-TABLE foo NO-UNDO FIELD a AS CHARACTER FIELD b AS CHARACTER FIELD c AS CHARACTER INDEX x a DESC b DESC c DESC. |
DEFINE TEMP-TABLE foo NO-UNDO FIELD a AS CHARACTER FIELD b AS CHARACTER FIELD c AS CHARACTER INDEX x a DESC b c. |
The following two temp-table definitions are also equivalent:
The following procedure creates a temp-table (temp-item) that stores the total inventory value (Item.Price * Item.OnHand) for each catalog page (Item.CatPage) in the sports2000 database. It builds temp-item with two indexes-one that sorts the table in ascending order by catalog page and a second that sorts the table in descending order by inventory value.
After building temp-item, the procedure displays a dialog box that prompts for report parameters. These parameters include the cutoff value of catalog page inventory to report, and whether to display the report by catalog page (ascending) or inventory value (descending). After displaying the report, the procedure displays another dialog box to repeat the process. The process is repeated until you press the CANCEL button. This procedure shows how you can use a temp-table to store a calculated result from the database, and efficiently report the same result according to different sorting and selection criteria:
r-tmptb1.p
DEFINE TEMP-TABLE temp-item FIELD cat-page LIKE Item.CatPage FIELD inventory LIKE Item.Price LABEL "Inventory Value" INDEX cat-page IS PRIMARY cat-page ASCENDING INDEX inventory-value inventory DESCENDING. DEFINE VARIABLE cutoff NO-UNDO LIKE item.price. DEFINE VARIABLE inv-value NO-UNDO LIKE item.price. DEFINE VARIABLE report-type AS INTEGER NO-UNDO INITIAL 1. DEFINE BUTTON ok-butt LABEL "OK" AUTO-GO. DEFINE BUTTON cancel-butt LABEL "CANCEL" AUTO-ENDKEY. FORM cutoff LABEL "Inventory Lower Cutoff for each Catalog Page" AT ROW 1.25 COLUMN 2 report-type LABEL "Report Sorted ..." AT ROW 2.25 COLUMN 2 VIEW-AS RADIO-SET RADIO-BUTTONS "By Catalog Page", 1, "By Inventory Value", 2 SKIP ok-butt cancel-butt WITH FRAME select-frame SIDE-LABELS WIDTH 70 TITLE "Specify Report ..." VIEW-AS DIALOG-BOX. FOR EACH Item BREAK BY Item.CatPage: ACCUMULATE Item.Price * Item.OnHand (SUB-TOTAL BY Item.CatPage). IF LAST-OF(Item.CatPage) THEN DO: inv-value = ACCUM SUB-TOTAL BY Item.CatPage (Item.Price * Item.OnHand). CREATE temp-item. temp-item.cat-page = Item.CatPage. inventory = inv-value. END. END. /* FOR EACH item */ ON CHOOSE OF ok-butt DO: HIDE FRAME select-frame. IF report-type = 1 THEN FOR EACH temp-item USE-INDEX cat-page WITH FRAME rpt1-frame: IF inventory >= cutoff THEN DISPLAY temp-item.cat-page inventory. END. ELSE FOR EACH temp-item USE-INDEX inventory-value WITH FRAME rpt2-frame: IF inventory >= cutoff THEN DISPLAY temp-item.cat-page inventory. END. VIEW FRAME select-frame. END. ENABLE ALL WITH FRAME select-frame. WAIT-FOR CHOOSE OF cancel-butt OR WINDOW-CLOSE OF CURRENT-WINDOW. |
For examples of instance and static temp-table data member definitions, see the descriptions of r-CustObj.cls, r-CustObjStatic.cls, and r-CustObjAbstract.cls in the CLASS statement reference entry.
If a trigger or internal procedure of a persistent procedure executes an external subprocedure that defines a SHARED temp-table, ABL includes the persistent procedure in the resolution of the corresponding NEW SHARED temp-table as though the procedure were on the procedure call stack.