If you use the LIKEother-table option or LIKE-SEQUENTIALother-table option for the temp-table, your temp-table is based on the other table you name. In this case, the following index rules apply:
If you do not specify any index information in the DEFINE TEMP-TABLE statement, the temp-table inherits all the index layouts defined for the other table.
If you specify one or more USE-INDEX options, the temp-table inherits only the indexes you name. If one of those indexes is the primary index of the other table, it becomes the primary index of the temp-table, unless you explicitly specify AS PRIMARY for another index you define.
If you specify one or more INDEX options in the definition, then the temp-table inherits only those indexes from the other table that you have named in a USE-INDEX phrase.
The primary index is the one the AVM uses by default to access and order records. The AVM determines the primary index in this way:
If you specify AS PRIMARY in a USE-INDEX phrase for an index inherited from the other table, then that is the primary index.
If you specify IS PRIMARY on an INDEX definition specific to the temp-table, then that becomes the primary index.
If you inherit the primary index from the other table, then that becomes the primary index for the temp-table.
The first index you specify in the temp-table definition, if any, becomes the primary index.
If you do not specify any index information at all, then the AVM creates a default primary index that sorts the records in the order in which they are created.
If you do not use the LIKE or LIKE-SEQUENTIAL options to use another table as the basis for your temp-table, then your temp-table only has indexes if you define them with the INDEX phrase in the definition.
You should use the same considerations you would use for a database table in determining what indexes, if any, to define or inherit for a temp-table. On the one hand, there is a small cost to creating index entries on update that could become measurable if you have multiple indexes with multiple fields, or if you are creating large numbers of records in a performance-intensive situation where many records are created between user actions. You should not create or use indexes your procedure will not need.
On the other hand, if you know that you need to access the records in the temp-table based on specific field values, then you should create or inherit the right indexes to let the AVM locate the records you need without having to read through the whole temp-table to find them. The OpenEdge database is tremendously efficient and you might find that it can locate specific records in your table based on nonindexed field values so quickly that you hardly notice the lack of an index for those fields. However, it is a good idea to define one or more indexes if your temp-table is going to have more than a handful of records and if you know which fields will be used to locate, filter, or sort records in the table. If your code does not need to access the records in the temp-table in any order other than the order in which they were created, then you do not need an index other than the default index the AVM gives you automatically.
If you do not specify any index information in the DEFINE TEMP-TABLE statement, the temp-table inherits all the index layouts defined for the other table.