ABAP Keyword Documentation → ABAP - Reference → Processing Internal Data → Internal Tables → Processing Statements for Internal Tables → MODIFY itab
MODIFY itab - itab_lines
Other versions: 7.31 | 7.40 | 7.54
... itab FROM wa [USING KEY keyname]
TRANSPORTING comp1 comp2 ... WHERE log_exp|(cond_syntax).
... USING KEY keyname
... WHERE log_exp
... WHERE (cond_syntax)
In this variant, the statement
MODIFY assigns the content of the components
comp1 comp2 ... of the work area
TRANSPORTING to all rows of the table
itab that meet the condition after
wa is a
functional operand position. The work area
wa must be
compatible with the row type of the internal table.
TRANSPORTING has the same effect as
changing individual rows. The addition
can only be specified together with the addition
Outside of classes, an obsolete short form is possible where
FROM wa can be omitted if the internal table has a
with the same name. The statement then uses the header line as the work area implicitly. Furthermore,
USING KEY cannot be specified without
Takes the content of the component
planetype for all rows in the internal
sflight_tab where this component contains the value
p_plane1 and changes it to the value
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 WHERE carrid = @p_carrid AND connid = @p_connid INTO TABLE @sflight_tab. sflight_wa-planetype = p_plane2. MODIFY sflight_tab FROM sflight_wa TRANSPORTING planetype WHERE planetype = p_plane1.
... USING KEY keyname
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.
Unlike the processing of a hashed table when a primary key is used, a preceding sort using the statement
SORThas no influence on the processing order when a secondary hash key is specified.
If a secondary table key is specified, any
WHEREcondition must be optimizable. Otherwise a syntax error occurs or an exception is raised.
... WHERE log_exp
WHERE condition. All rows are processed for which the condition after
WHERE is met. If a static
WHERE condition is specified,
the row type of the internal table must be statically identifiable.
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
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.
- 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
- When using a sorted key or a
hash key (that is, when accessing a
sorted table, a
hashed table, or a
secondary table key),
an attempt is made to optimize the access as described under
Optimization of the
WHERECondition. If the following prerequisites are not met:
- the entire logical expression (or a part of the expression) can be transformed to a key access,
- the transformable part of the logical expression has the same result as the resulting key access,
WHEREcondition 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.
When using a
WHEREcondition, 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 KEYand
WITH KEYof the statement
READare used or if the appropriate keys are specified in table expressions, 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
WHEREcondition to be optimized.
If a comparison expression with a
selection table is specified after
INas a logical expression, note that the expression at the initial table is always true and then all rows are edited.
... WHERE (cond_syntax)
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
condition) or is initial. The following are not supported in a dynamic
- String expressions and bit expressions
- String functions and bit functions
- Constructor expressions
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
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.
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
Security Risks of Input from Outside.
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.