Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Processing Internal Data →  Internal Tables →  Processing Statements for Internal Tables →  MODIFY itab 

MODIFY itab - itab_lines

Short Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax


... itab FROM wa [USING KEY keyname] 

         TRANSPORTING
comp1
comp2 ... WHERE log_exp|(cond_syntax).

Extras

1. ... USING KEY keyname

2. ... WHERE log_exp

3. ... WHERE (cond_syntax)

Effect

In this variant, the statement MODIFY assigns the content of the components comp1 comp2 ... of the work area wa specified after TRANSPORTING to all rows of the table itab that meet the condition after WHERE. wa is a functional operand position. The work area wa must be compatible with the row type of the internal table.

The addition TRANSPORTING has the same effect as changing individual rows. The addition WHERE can only be specified together with the addition TRANSPORTING.


Note

Outside of classes, an obsolete short form is possible where FROM wa can be omitted if the internal table has a header line itab with the same name. The statement then uses the header line as the work area implicitly. Furthermore, USING KEY cannot be specified without USING KEY.


Example

Takes the content of the component planetype for all rows in the internal table sflight_tab where this component contains the value p_plane1 and changes it to the value p_plane2.

PARAMETERS: p_carrid TYPE sflight-carrid, 
            p_connid TYPE sflight-connid, 
            p_plane1 TYPE sflight-planetype, 
            p_plane2 TYPE sflight-planetype. 

DATA sflight_tab TYPE SORTED TABLE OF sflight 
                 WITH UNIQUE KEY carrid connid fldate. 

DATA sflight_wa TYPE sflight. 

SELECT * 
       FROM sflight 
       INTO TABLE sflight_tab 
       WHERE carrid = p_carrid AND 
             connid = p_connid. 

sflight_wa-planetype = p_plane2. 

MODIFY sflight_tab FROM sflight_wa 
       TRANSPORTING planetype WHERE planetype = p_plane1.

Addition 1

... USING KEY keyname

Effect

The USING KEY addition can be used to specify a table key in keyname used to carry out the processing. The specified table key influences the order in which the table rows are accessed, and the evaluation of the remaining conditions.

If the primary table key is specified, the processing behaves in the same way as when no key is explicitly specified. If a secondary table key is specified, the order in which the rows are accessed is as follows:

  • Sorted key specified
    The rows are processed by ascending row number in the secondary table index
  • Hash key specified
    The rows are processed in the order in which they were inserted into the table.


Notes

  • Unlike the processing of a hash table when a primary key is used, a preceding sort using the SORT statement has no influence on the processing sequence when a secondary hash key is specified.
  • If a secondary table key is specified, any WHERE condition must be optimizable. Otherwise a syntax error occurs or an exception is raised.

Addition 2

... WHERE log_exp

Effect

Static WHERE condition. All rows are processed for which the condition after WHERE is met. You can specify WHERE for all table categories.

You can specify a logical expression log_exp after WHERE in which the first operand of each operation is a component of the internal table. You cannot specify a predicate function. The components of the internal table must be specified as individual operands and not as part of an expression. You cannot use parenthesized character-like data objects to specify a component dynamically here. The remaining operands of a comparison are general expression positions at which any suitable inidividual operands or expressions can be specified, but no components of the internal table. All logical expressions are possible except IS ASSIGNED, IS SUPPLIED, and the obsolete IS REQUESTED. The specified components can have any data type. The relevant comparison rules apply to the evaluation.

  • When standard tables are accessed without a secondary key being specified, the access is not optimized. This means that all rows of the internal table are tested for the logical expression of the WHERE addition.
  • the logical expression cannot be transformed to a key access
  • the logical expression has the same result as the resulting key access
then no optimization takes place when a sorted table or a hashed table is accessed using the primary table key. Any access using a secondary table key produces a syntax error or exception. If the remaining prerequisites for the optimization are met, then the static WHERE condition cannot contain any duplicate or overlapping key specifications.


Notes

  • When using a WHERE condition, note that the comparison rules for incompatible data types apply when comparing incompatible data objects. Here, the data types involved determine which operand is converted. If the additions WITH TABLE KEY and WITH KEY of the statement READ are used, however, the content of the specified data objects is always converted to the data type of the columns before the comparison. This can produce varying results.
  • If possible, all operands of the logical expression should be in compatible pairs, so enabling the WHERE condition to be optimized.
  • If a selection table is specified after IN as a logical expression, note that the expression at the initial table is always true and then all rows are edited.

Addition 3

... WHERE (cond_syntax)

Effect

Dynamic WHERE condition. You can declare a character-type data object or standard table with character-type data type for cond_syntax. This data object or standard table is initial or contains the syntax of a logical expression (in accordance with the rules of the static WHERE condition) when the statement is executed.

As in ABAP Editor, the syntax in cond_syntax is not case-sensitive. When you declare an internal table, you can distribute the syntax across multiple rows. If cond_syntax is initial when the statement is executed, the logical expression is true. An invalid logical expression raises an exception of the class CX_SY_ITAB_DYN_LOOP.

The obsolete logical operators (><, =>, and =<) are not supported by cond_syntax.


Notes