ABAPMODIFY_ITAB_MULTIPLE - MODIFY ITAB MULTIPLECPI1466 during Backup TXBHW - Original Tax Base Amount in Local Currency
This documentation is copyright by SAP AG.
MODIFY itab, itab_lines
In this variant, the statement MODIFY assigns the content of the components comp1 comp2 ... of the work area wa specified after TRANSPORTING to all lines 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 line type of the internal table.
The addition TRANSPORTING has the same effect as
changing individual lines. The addition WHERE can only be specified together with the addition TRANSPORTING.
Outside of classes, an obsolete short form is possible where FROM wa can be omitted if the internal table has an identically named
itab. The statement then uses the header line as the work area implicitly. Furthermore, USING KEY cannot be specified without FROM wa.
... WHERE log_exp
Static WHERE condition. All rows are processed for which the condition after WHERE is met. You can declare WHERE for all table categories.
After WHERE, you can declare a logical expression log_exp 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 declared as individual operands and not as part of an expression. You cannot use parenthesized character-type data objects to declare a component dynamically here. The remaining operands of an operation can be any suitable individual operands or calculation expressions, but not components of the internal table. All logical expressions are possible except for the IS ASSIGNED, IS SUPPLIED, and obsolete IS REQUESTED predicates. The specified components can be of any data type. For evaluations, the relevant comparison rules apply.
When standard tables are accessed without a secondary key being specified, access is not optimized since all rows of the internal table are checked for the logical expression of the WHERE addition.
If a sorted key
is declared, the logical expression uses comparisons linked with AND with the relational operator
= (or EQ) to include an initial part of the key that consists of at least one component. An AND operation with further comparisons is possible.
If a hash key is
declared, the logical condition uses comparisons linked with AND with the relational operator
= (or EQ) to include all components of the key. An AND operation with further comparisons is possible
The logical expression selects the same rows as a READ TABLE statement, in which the relevant components are specified as keys.
If the prerequisites for accessing a sorted or hashed table by means of the primary key are not met, optimization is not achieved and all rows of an internal table are checked as with standard tables.
,,When a secondary
table key is accessed, that is, if one is specified in keyname after USING KEY, optimized
execution is ensured, provided that the prerequisites above are met. Otherwise, a syntax error or exception occurs.
When using a WHERE condition, note that the
comparison rules for incompatible data types
apply when incompatible data objects are compared, whereby the data types involved determine which operand
is converted. In contrast, when the WITH
TABLE KEY and WITH KEY
additions of the READ statements are used, the content of the specified data objects is always converted into the data type of the columns before the comparison is made, which can lead to different results.
When access is optimized, the WHERE condition is mapped internally to a READ statement with specification of the relevant key.
Since the WHERE condition can only optimized if it produces the same results as a READ statement with the corresponding key specification, all operands of the logical expression should be
pairs, if possible. This ensures that the result is not affected by the different behavior of the WHERE condition and the READ statement with a key specification.
If a selection
table is specified after IN
as a logical expression, note that the expression for the initial table is always true and all rows are then processed.
In the column col2 of the internal table itab, the MODIFY statement replaces every negative value with the number 0.
... USING KEY keyname
Using the USING KEY addition, a table key can be specified in keyname with which processing is carried out. The specified table key influences the sequence in which the table rows are accessed, and the evaluation of the remaining conditions.
If the primary table key is specified, processing behaves in the same way as when no key is explicitly specified. If a secondary table key is specified, the sequence in which the rows are accessed is as follows:
Specification of a sorted key
The rows are processed by ascending row number in the secondary table index
Specification of a hash key
The rows are processed in the sequence in which they were inserted into the table.
In contrast to processing 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.
- Unlike the processing of a hashed table when a primary key is used, a preceding sort using the statement SORT has no effect 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.
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 in an optimized way using the secondary key mkey.
... WHERE (cond_syntax)
Dynamic WHERE Condition cond_syntax can be specified as a character-like data object or standard table with character-like data type that, when the statement is executed, contains the syntax of a logical expression (in accordance with the rules of the static WHERE condition) or is initial.
The syntax in cond_syntax is, as in the ABAP Editor, not case-sensitive. When specifying an internal table, you can distribute the syntax over multiple rows. If cond_syntax is initial when the statement is executed, the logical expression is true. Invalid logical expressions trigger an exception from the class CX_SY_ITAB_DYN_LOOP.
The obsolete relational operators (><, =>, and =<) are not supported in cond_syntax.
Of the calculation expressions, only
arithmetic expressions are currently supported.
String expressions and
bit expressions are not supported.
String functions and
bit functions cannot be specified either.
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.
Like the example for static WHERE conditions, but with a condition for the column col2 that can be entered dynamically.
RFUMSV00 - Advance Return for Tax on Sales/Purchases PERFORM Short Reference
This documentation is copyright by SAP AG.
Length: 13887 Date: 20231210 Time: 091544 sap01-206 ( 210 ms )