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

MODIFY itab - itab_lines

Quick 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. ... WHERE log_exp

2. ... USING KEY keyname

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 FROM wa.

Addition 1

... WHERE log_exp

Effect

Static 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 known statically. 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. The following can be specified as relational expressions:

• All comparison expressions
• The following predicate expressions:
  

• IS [NOT] INITIAL

• IS [NOT] BOUND

• IS [NOT] INSTANCE OF

No other predicates can be specified. 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 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 usual comparison rules apply to the evaluation. Here, a different rule applies to a string expression on the right side than to general logical expressions.

• 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.

• 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 WHERE Condition. If the corresponding 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,

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

• 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 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 the WHERE condition to be optimized.
• If a comparison expression with a ranges 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.
  

Example

In the column col2 of the internal table itab, the MODIFY statement replaces every negative value with the number 0.

TYPES: 
  BEGIN OF line, 
    col1 TYPE c LENGTH 1, 
    col2 TYPE i, 
  END OF line. 

DATA itab TYPE SORTED TABLE OF line 
               WITH UNIQUE KEY col1. 

DATA(rnd) = cl_abap_random_int=>create( seed = + sy-uzeit 
                                      min  = 1 
                                       max  = 20 ). 

itab = VALUE #( FOR i = 1 UNTIL i > 26 
                ( col1 = substring( val = sy-abcde 
                                   off = i - 1 
                                   len = 1 ) 
                                   col2 = rnd->get_next( ) - 10 ) ). 

MODIFY itab FROM VALUE line( col2 = 0 ) TRANSPORTING col2 
            WHERE col2 < 0. 

Addition 2

... 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 hashed table when a primary key is used, a preceding sort using the statement SORT has no influence on the processing order 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.
  

Example

In the internal table itab, the MODIFY statement replaces the value in the column col1 with "_" if the column col2 contains the value 0. The WHERE condition is evaluated (and the evaluation optimized) using the secondary key mkey.

TYPES: 
  BEGIN OF line, 
    col1 TYPE c LENGTH 1, 
    col2 TYPE i, 
  END OF line. 

DATA itab TYPE TABLE OF line 
               WITH EMPTY KEY 
               with NON-UNIQUE SORTED KEY mkey COMPONENTS col2. 

DATA(rnd) = cl_abap_random_int=>create( seed = + sy-uzeit 
                                      min  = 1 
                                       max  = 10 ). 

itab = VALUE #( FOR i = 1 UNTIL i > 26 
                ( col1 = substring( val = sy-abcde 
                                   off = i - 1 
                                   len = 1 ) 
                                   col2 = rnd->get_next( ) - 5 ) ). 

MODIFY itab FROM VALUE line( col1 = '_' ) USING KEY mkey 
            TRANSPORTING col1 WHERE col2 = 0. 

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:

• String expressions and bit expressions
• String functions and bit functions
• Time stamp functions with the exception of utclong_current
• Constructor expressions
• Table expressions
  

The syntax in cond_syntax is not case-sensitive (as in the static syntax). 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 Caused by Input from Outside.

Note

The dynamic WHERE condition 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.

Example

Like the example for static WHERE conditions, but with a condition for the column col2 that can be entered dynamically.

DATA condition TYPE string VALUE '< 0'. 
cl_demo_input=>request( CHANGING field = condition ). 
condition = `col2 ` && condition. 

TYPES: 
  BEGIN OF line, 
    col1 TYPE c LENGTH 1, 
    col2 TYPE i, 
  END OF line. 

DATA itab TYPE SORTED TABLE OF line 
               WITH UNIQUE KEY col1. 

DATA(rnd) = cl_abap_random_int=>create( seed = + sy-uzeit 
                                      min  = 1 
                                       max  = 20 ). 

itab = VALUE #( FOR i = 1 UNTIL i > 26 
                ( col1 = substring( val = sy-abcde 
                                   off = i - 1 
                                   len = 1 ) 
                                   col2 = rnd->get_next( ) - 10 ) ). 
TRY. 
    MODIFY itab FROM VALUE line( col2 = 0 ) TRANSPORTING col2 
               WHERE (condition). 
    cl_demo_output=>display( itab ). 
  CATCH cx_sy_itab_dyn_loop INTO DATA(exc). 
    ... 
ENDTRY.