Try OpenEdge Now
skip to main content
ABL Essentials
Defining and Using Temp-tables : Using temp-tables in your application : Defining a temp-table : Defining fields for the temp-table
 
Defining fields for the temp-table
If you use the LIKE or LIKE-SEQUENTIAL options on your temp-table definition, the temp-table inherits all the field definitions for all the fields in the other table. The definitions include all of these attributes:
*The field name
*The field's data type and, for an array field, its extent
*The field's initial value
*The field's label and column-label
*The field's format and, for a DECIMAL field, the number of decimals
*The field's help text, if any
*The field's font and color
*The field's record position when using the LIKE option
Note: If you use the LIKE-SEQUENTIAL option and the source is a database, record position is taken from the metaschema _field._order field.
Whether you use the LIKE or LIKE-SEQUENTIAL options to base your temp-table on another table or not, you can also use the FIELD phrase to define one or more fields for the temp-table. If you use the LIKE or LIKE-SEQUENTIAL options, then any fields you define with the FIELD phrase are additional fields beyond the fields inherited from the other table. If you do not use the LIKE or LIKE-SEQUENTIAL options, then these are the only fields in the temp-table.
For fields you define individually with the FIELD phrase, you must specify at least the field name and data type, or use the LIKE phrase to define the field to be LIKE a field from another table. If you use the LIKE phrase on an individual field, your field inherits all of its attributes by default. You can override any of the field attributes of an inherited field except for the name, data type, and array extent, by using the appropriate keywords such as LABEL, FORMAT, and INITIAL. You can find a complete description of these keywords under the Field Options topic in the online help. You can also define the same attributes for fields that are not inherited from another table using the same keywords on the FIELD phrase.
You can use the FIELD phrase for one of three purposes:
*If you want to base your temp-table on another table, but you do not want all of its fields or you want to change some of the field attributes, including even the field names, then you can name the individual fields using the FIELD phrase rather than making the whole table LIKE or LIKE-SEQUENTIAL the other table. You then specify each field to be LIKE a field from the other table, possibly with a different name or modified attributes.
If you only need to change certain display attributes of some of the fields, but otherwise want to use all the fields from the other table, you can use the LIKE or LIKE-SEQUENTIAL options on the temp-table definition to base it on the other table. You then modify the field attributes in the definition of the browse or frame fields where they are displayed. This makes your temp-table definition simpler than if you explicitly named each field just to change a few attributes of some of the fields.
*If you want to base your temp-table on another table, but you want some additional fields from one or more other tables as well, then you can define the temp-table to be LIKE or LIKE-SEQUENTIAL the other table, and then add FIELD phrases for each field that comes from another related table. You can use the LIKE keyword on these additional fields to inherit their database attributes as well.
*If you need fields in your table that are not based at all on specific database fields, then you define them with the FIELD phrase. Again, you can do this whether the basic temp-table definition is LIKE or LIKE-SEQUENTIAL another table or not.
You can define temp-tables with all the ABL data types that you can use for database fields (CHARACTER, DATE, DECIMAL, INTEGER, LOGICAL, RECID, CLOB, BLOB, and RAW). Note that CLOBs and BLOBs were introduced to ABL in OpenEdge Release 10.0A.
In addition, you can define a temp-table field to be of type ROWID, which is something you cannot do with fields in database tables. You could use such a field to store the RowID of a record you read from a database, in order to use the RowID to relocate the record later in the procedure.