Kontakt

Ansicht
Dokumentation

ABAPREAD_TABLE_FREE - READ TABLE FREE

ABAPREAD_TABLE_FREE - READ TABLE FREE

Addresses (Business Address Services)   PERFORM Short Reference  
This documentation is copyright by SAP AG.
SAP E-Book

READ TABLE, free_key

Short Reference



... WITH KEY ${ comp1 = operand1 comp2 = operand2 ... $[BINARY SEARCH$] $}
           $| ${ keyname COMPONENTS comp1 = operand1 comp2 = operand2 ... $} ...

Variants:

1. ... WITH KEY comp1 = operand1 comp2 = operand2 ... $[BINARY SEARCH$] ...

2. ... WITH KEY keyname COMPONENTS comp1 = operand1 comp2 = operand2 ... .

Effect

Specifies a free search key. The free search key can be defined freely or linked to the specification of a secondary table key in keyname.

Notes

  • Table expressions allow corresponding reads to also be performed in operand positions. The free key search is used if components are specified without an explicit key specified.
  • Outside of classes, the two obsolete variants of the addition WITH KEY are possible.

Variant 1

... WITH KEY comp1 = operand1 comp2 = operand2 ... $[BINARY SEARCH$] ...


Addition:

... BINARY SEARCH

Effect

After the addition WITH KEY, components comp1 comp2 ... can be specified as search keys, in accordance with the rules here. An operand operand1 operand2 ... is assigned to each of these search keys and must be compatible with the data type of the component or convertible to it. No duplicate or overlapping keys may be specified.

operand1 operand2 ... are general expression positions. If necessary, the content of the operands is converted to the data type of the components before the comparison. If an arithmetic expression is specified, the calculation type is determined from its operands and the data type of the component. If necessary, the result is converted to the data type of the component.

The system searches for the first line of the internal table whose values in the specified components or their subareas or attributes match the values in the assigned operands operand1 operand2 ...

The search is performed as follows for the individual table categories if BINARY SEARCH is not specified:

  • Sorted tables are searched binarily if the specified search key is an initial part of the primary table key or includes this key; otherwise the search is linear.
  • Hashed tables are searched using the hash algorithm if the specified search key is an initial part of the primary table key or includes this key; otherwise the search is linear.

If the name field of a component comp is initial, the first line that matches the remaining search key is read. If all name fields are initial, the first line of the internal table is read.

When a line is found, the system field sy-tabix is set according to the table category:

  • For index tables to the number of lines found in the primary table index
  • For hashed tables to the value 0.

If no line is found, sy-tabix is undefined (-1), except if the complete table key or the addition BINARY SEARCH was specified in a sorted table. In this case, sy-tabix is set to the line number of the entry in the primary table index in front of which the line would be inserted using INSERT ... INDEX ..., to preserve the sort.

Notes

  • If the line type of the internal table is not known statically, the components of the search key can only be specified dynamically and not directly.
  • If the search key includes components that supply a secondary table key of the internal table without the key being specified in keyname, a warning is raised by the syntax check.
  • If the BINARY SEARCH addition is used, and there are multiple hits, either due to an incompletely specified search key or duplicate table entries, the first hit based on the sequence of lines is the primary index, that is, the line with the lowest line number, is always returned.
  • If WITH KEY is used, it should be noted that the values of incompatible operands operand1 operand2 ... are converted to the data type of the columns before the comparison. This means that the comparison rules do not apply to incompatible data types. If a WHERE condition is used in the statements LOOP, MODIFY, and DELETE, however, the comparison rules apply, which can produce different results.
  • Due to the conversion before the comparison, enumerated objects can be specified as operands for character-like types of type c or string and the corresponding special conversion rules apply, which is not possible in a WHERE condition. This type of conversion produces a message from the extended syntax check.
  • To avoid unexpected results after a conversion, operand1, operand2, ... must be compatible with the data type of the component.

Example

The internal table html_viewer_tab contains references to HTML controls. The READ statement reads the reference that points to a HTML control in a specific container control.

Addition

... BINARY SEARCH

Effect

The addition BINARY SEARCH searches the table binarily instead of linearly. For larger tables (from approximately 100 entries), this can significantly reduce runtime. The table must, however, be sorted in ascending order by the components specified in the search key. The priority of the sort order must match exactly the order of the components in the search key. If this requirement is not met, the correct line is not usually found.

  • The addition BINARY SEARCH can only be specified for sorted tables if the specified search key is in the correct order and is an initial part of the table key, or includes the key. It has no special effect in this situation.
  • The addition BINARY SEARCH cannot be specified for hashed tables.

Notes

  • If the addition BINARY SEARCH is used, the statement READ always performs an index access, and can therefore only be used for tables with the appropriate type. Formal parameters or a field symbol must have at least the generic type INDEX TABLE.
  • The addition BINARY SEARCH is based on standard sorting according to the size of the components. Text sorting with the addition AS TEXT of the statement SORT can produce unexpected results, since the result for text-like components no longer depends on the binary representation, but on the locale of the current text environment.
  • The method READ_BINARY_SEARCH_CHECK of the class CL_ABAP_ITAB_UTILITIES can be used to check whether the required sorting exists for the addition BINARY SEARCH.
  • When the addition BINARY SEARCH is used, if there are multiple hits due to an incomplete search key or duplicate entries in the table, the first hit according to the order of the lines in the primary index is returned. This is the line with the lowest line number.

Example

Reading of a table line with BINARY SEARCH after the table has been sorted accordingly. However, if possible sflight_tab should be created as a sorted table or given a sorted secondary key afterwards (see example below).



Variant 2

... WITH KEY keyname COMPONENTS comp1 = operand1 comp2 = operand2 ...


Effect

keyname can be used to specify a table key. The same applies when specifying the components as in the variant without key specifications.

If a secondary table key is specified in keyname, the behavior is as follows:

  • If a sorted key is specified, the specified search key must be an initial part of the secondary table key or include it. The associated secondary table index is then searched binarily. If multiple entries are found when using a non-unique search key, the first hit, that is, the line with the lowest line number, is read in the secondary index. Additional search criteria can also be specified that are also evaluated.
  • If a hash key is specified, the specified search key must include the secondary table key and the hash algorithm is used. Additional search criteria can also be specified that are also evaluated.

When a line is found, the system field sy-tabix is set with respect to the specified secondary table key:

  • For sorted secondary keys to the number of the found line in the associated secondary table index
  • For hash keys to the value 0.

If no line is found, sy-tabix is undefined (-1), except when it is covered completely by a sorted secondary key. In this case, sy-tabix is set to the line number of the entry in the secondary table index in front of which the line would be inserted using INSERT ... INDEX ..., to preserve the sort.

If the primary table key is specified in keyname using its name primary_key, the behavior is the same as in the variant without key specifications.

Notes

  • The specification of free keys differs when a secondary key is used from the table_key variant for specifying the table key in that additional conditions can be specified in the search key. These conditions can also be evaluated and reduce the length of the hit list. For secondary sorted keys, however, free search keys make it possible to specify an incomplete search key, which can make the hit list longer.
  • If a secondary table key is used, when the value of sy-tabix is used subsequently as an index specification in other processing statements for the internal table, it must be ensured that the same table key is used.

Example

Reading of a table line using the sorted secondary table key dbkey. The read is now performed automatically using a binary search, as in the example above where BINARY SEARCH is specified explicitly, and an explicit sort is not necessary.

Example

The DEMO_SECONDARY_KEYS program demonstrates the specification of a secondary table key compared to the completely free specification of a key and the resulting performance benefits.






BAL Application Log Documentation   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.

Length: 16523 Date: 20240425 Time: 154746     sap01-206 ( 249 ms )