MODIFY - Changing Individual Rows in an Internal Table

Variants:

1. MODIFY itab [FROM wa] [INDEX idx] [ASSIGNING <fs>|REFERENCE INTO dref] [TRANSPORTING f1 ... fn].

2. MODIFY TABLE itab [FROM wa] [ASSIGNING <fs>|REFERENCE INTO dref] [TRANSPORTING f1 ... fn].

3. MODIFY itab [FROM wa] TRANSPORTING f1 ... fn WHERE cond.

Changing the content of individual lines in an internal table. With sorted or hashed tables you must not change the content of the table key.

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Short Forms in Line Operations.

Variant 1

MODIFY itab [FROM wa] [INDEX idx] [ASSIGNING <fs>|REFERENCE INTO dref] [TRANSPORTING f1 ... fn].


Effect

Changes a single entry in the internal table itab, specifying the index explicitly or implicitly. You can only use this variant with index table (standard or sorted tables).

If you specify "FROM wa", the new values are taken from the work area wa. If you do not specify FROM, the header line of itab is used as the work area.

You can use "INDEX idx" to specify the table index of the line you want to change. This may be omitted within a LOOP at an internal table. In this case, the current table line is changed.
The INDEX specification can come before the FROM addition.

If you use the addition ASSIGNING <fs>, the field symbol <fs> is set to the modified line. If you use the addition REFERENCE INTO ref, the data reference dref is filled with the reference of the modified line. Both the field symbol and the reference are only set if the statement is processed successfully.

If you specify "TRANSPORTING f1 ... fn ", only components f1, f2, ... of the work area are copied into the table. You can also specify components dynamically in the form (name). The actual component name is then taken from the field name at runtime. If name contains an invalid component name, the system triggers a runtime error. In HASHED or SORTED tables, you cannot use a TRANSPORTING field as a key field.

The Return Code is set as follows:

When you specify the insertion point with INDEX idx:

SY-SUBRC = 0:
The entry was changed.
SY-SUBRC = 4:
Index position too large. No entry was changed, since the table contains less than idx entries.

If you do not specify an insertion point, Return Code is set to 0.

Variant 2

MODIFY TABLE itab [FROM wa] [ASSIGNING <fs>|REFERENCE INTO dref] [TRANSPORTING f1 ... fn].


Effect

Generic change to a single entry in the internal table itab with key. Unlike variant 1, you can use this variant for any table. All additions have the same meaning as for variant 1.

The key of the entry to be changed is taken from the work area. The procedure depends on the table type:

The Return Code is set as follows:

SY-SUBRC = 0:
The first entry with the specified key was changed.
SY-SUBRC = 4:
There was no entry with the specified key.

Variant 3

MODIFY itab [FROM wa] TRANSPORTING f1 ... fn WHERE cond.


Effect

Changes several entries in the internal table itab. You can use this variant for any table.

You can use " FROM wa" and "TRANSPORTING f1 ... fn" as in variant 1. If the table has the type SORTED TABLE or HASHED TABLE, the TRANSPORTING list may not contain key fields.

In comparisons within the logical expression cond, the first operand must always be a subfield of the line structure of itab.

The Return Code is set as follows:

SY-SUBRC = 0:
At least one entry was changed.
SY-SUBRC = 4:
None of the entries was changed.

Notes

  1. When you use the WHERE condition with a STANDARD or HASHED table, a full table scan is always required.

    If you are working with a SORTED TABLE, the partial sequential processing can be optimized so that only the entries that actually satisfy the WHERE condition are processed. This optimization requires that each sub-condition is linked with AND; that no parentheses are used; that at least one sub-condition is in the form k = v; and that the conditions in the form k1 = v1 ... kn = vn cover at least the first part of the table key.

    The starting point for the loop is specified using a binary search with the sub-conditions that cover the table key (partially or completely). This optimization is similar to the optimization in the READ statement. The loop is only processed from the starting point to the point where these sub-conditions are still met. (See also Optimized Key Operations in Internal Tables).

  2. You can replace any operand in the WHERE condition with a functional method - unless it is a subfield in a line structure of the relevant internal table. Functional methods are methods in ABAP Objects that can have any number of IMPORTING parameters, but have only one RETURNING parameter.

  3. If the line type of the internal table is - or contains - object reference variables, the attributes of the object (to which the reference of the line points) can be used as comparison values in the WHERE condition. (See Object Attributes as Keys in Internal Tables).



Example

Reset a status flag universally

DATA: BEGIN OF TAB OCCURS 500,
        FLAG     TYPE C,
        COMP(20) TYPE C,
      END OF TAB.

CLEAR TAB-FLAG.
MODIFY TAB TRANSPORTING FLAG WHERE FLAG = 'X'.

Notes

General:

  1. If you use the TRANSPORTING addition together with an explicitly-specified work area, the work area must be compatible with the line type of the internal table.

  2. The counter for table entries begins at 1.

  3. A unique or summarized dataset built up using an internal table and COLLECT can be modified while you are constructing it using the "MODIFY ... TRANSPORTING ..." statement, as long as the components selected with TRANSPORTING are not contained in the key of the internal table. This method does not cause significant performance impairment.


Notes

Performance:

  1. You can save unnecessary assignments if you use statements that use a specific work area with internal tables with header lines.


  2. The runtime required to change an entry in a table 100 bytes wide using an index is around 5 msn (standardized microseconds).


  3. If you only want to change individual fields within a complex line structure, it is quicker to use " TRANSPORTING f1 f2 ..." than the simple MODIFY statement. This applies particularly if you can use the TRANSPORTING addition to eliminate tabular components.


Exceptions

Non-Catchable Exceptions

Related

APPEND itab, INSERT itab, COLLECT itab

Additional help

Changing Lines in Tables

Changing Lines in Tables Using the Index