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

MODIFY itab - itab_lines

Short Reference

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:

Notes

Addition 2

... WHERE log_exp

Effect

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

A logical expression log_exp can be specified after WHERE, in which the first operand of each relational expression is a component of the internal table. Any comparison expression and the predicate expression IS INITIAL can be specified as relational expressions. Other predicates cannot be specified. The components of the internal table must be specified as individual operands and not as part of an expression. Parenthesized character-like data objects cannot be used to specify a component dynamically here. The remaining operands of a relational expression are general expression positions at which any suitable individual operands or expressions can be specified, but no components of the internal table. The specified components can have any data type. The relevant comparison rules apply to the evaluation.

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. In the part of the logical expression relevant for the optimization, the static WHERE condition cannot specify any duplicate or overlapping keys. Duplicate key components can, however, be specified in the part of the logical expression whose relational expressions do not make a contribution to the optimized access.

Notes

Addition 3

... WHERE (cond_syntax)

Effect

Dynamic WHERE Condition cond_syntax can be specified as a character-like data object or standard table with character-like row type that, when the statement is executed and with the following exceptions, contains the syntax of a logical expression (in accordance with the rules of the static WHERE condition) or is initial. The following are not supported in a dynamic WHERE condition:

The syntax in cond_syntax is, as in the ABAP Editor, not case-sensitive. When an internal table is specified, the syntax can be distributed across multiple rows. If cond_syntax is initial when the statement is executed, the logical expression is true. Invalid logical expressions raises an exception from the class CX_SY_ITAB_DYN_LOOP.

Security Note

If used wrongly, dynamic programming techniques can present a serious security risk. Any dynamic content that is passed to a program from the outside must be checked thoroughly or escaped before being used in dynamic statements. This can be done using the system class CL_ABAP_DYN_PRG or the predefined function escape. See Security Risks of Dynamic Programming.

Note

The dynamic WHERE conditions is not evaluated for a blank table for optimization reasons. Therefore, if an internal table is blank, and a logical expression has errors, no exception is raised.