Kontakt

Ansicht
Dokumentation

ABAPDELETE_ITAB_LINES - DELETE ITAB LINES

ABAPDELETE_ITAB_LINES - DELETE ITAB LINES

General Material Data   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.
SAP E-Book

DELETE itab, itab_lines

Short Reference



... itab $[USING KEY keyname$] $[FROM idx1$] $[TO idx2$]
                             $[STEP n$]$|$[WHERE log_exp$|(cond_syntax)$] ...

Additions

1. ... USING KEY keyname

2. ... $[FROM idx1$] $[TO idx2$]

3. ... STEP n

4. ... WHERE log_exp

5. ... WHERE (cond_syntax)

Effect

To delete multiple lines, at least one of the additions FROM, TO, STEP, or WHERE must be specified. USING KEY keyname is used to determine the table key to which the additions refer.

If multiple additions are specified, the lines that result from the intersection of the individual additions are deleted.

Addition 1

... USING KEY keyname

Effect

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.

Note

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.

Notes

  • Unlike the processing of a hashed table when a primary key is used, a preceding sort using the statement SORT has no affect on the processing order when a secondary hash key is specified.
  • If a secondary table key is specified, any WHERE condition also specified must be optimizable. Otherwise a syntax error occurs, or an exception is raised.

The statement DELETE deletes the first three lines of the internal table itab because they occur from line 4 in the secondary table index of the secondary key skey.

Addition 2

... $[FROM idx1$] $[TO idx2$]

Effect

If you use these additions, only the table rows from row number idx1, or up to row number idx2, are taken into account in the table index used. If only FROM is specified, all rows of the table from row number idx1 up to and including the last row are taken into account. If only TO is specified, all rows in the table from the first row up to row number idx2 are taken into account.

If the addition USING KEY is not used, or the primary table key is specified in keyname, the additions FROM and TO can only be used for index tables. In this case, they refer to the row numbers of the primary table index.

If a sorted secondary key is specified in keyname after USING KEY, the additions FROM and TO can be used for all table types and refer to the row numbers of the secondary table index.

idx1 and idx2 are numerical expression positions of operand type i. The following restrictions apply:

  • If the value of idx1 is less than or equal to 0, it is set to 1 in the LOOP statement and causes a runtime error in every other statement. If the value of idx1 is greater than the total number of table rows, no processing takes place.

  • If the value of idx2 is less than or equal to 0, the LOOP statement is not carried out and in every other statement it leads to a runtime error. If the value of idx2 is greater than the number of table rows, it is set to the number of table rows.

  • If the value of idx2 is less than the value of idx1, no processing takes place.

The additions FROM and TO can be specified together with STEP and then special rules apply.

Note

The statement DELETE FROM itab has the statement DELETE FROM dbtab with identical syntax. If an internal table has the same name as a database table, a statement like this accesses the internal table.

Example

Deletion of all lines in an internal table from line 4. The result is the same as in the example for APPEND .... SORTED BY.

Addition 3

... STEP n

Effect

The optional addition STEP n defines the step size for processing an internal table. The step size is defined by the value of n which must be positive. n is a numeric expression position of operand type i. If the addition STEP is not specified, the step size is 1.

The step size can be combined with the additions FROM and TO and then works on the subset of table lines defined by these conditions. If FROM idx1 and TO idx2 are combined with STEP, idx1 needs to be less than or equal to idx2.

Depending on the value of n, every nth line is processed. The value of n must not be 0. For more details, see LOOP AT itab, cond.

Notes

  • STEP n cannot be used in combination with WHERE.
  • In contrast to the STEP addition for LOOP AT, the processing order cannot be changed by negative values of n here. The processing order is only defined by the table category or the addition USING KEY.
  • STEP n can, however, be positioned otherwise. Its use after FROM idx1 and TO idx2 is recommended.

Example

The following example shows that every second table line between line 1 and 8 is deleted from the internal table.

Exceptions

Non-Catchable Exceptions

  • Cause: Illegal step size for the statement.
    Runtime Error: ITAB_ILLEGAL_STEP_SIZE
  • Cause: The statement only supports integral data objects.
    Runtime Error: OBJECTS_NOT_INTEGRAL

Addition 4

... WHERE log_exp

Effect

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.

When a sorted key or a hash key is used, that is, when a sorted table, a hashed table, or a secondary table key is accessed, access is optimized in the following circumstances:

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

Notes

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

Example

Optimized deletion of a line by specifying the unique primary table key and multiple lines by specifying a non-unique secondary table key in two DELETE statements.

Deleting Lines Using WHERE

Addition 5

... WHERE (cond_syntax)

Effect

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.

Notes

Example

Deletion of the lines of an internal table using a condition that can be entered for the table lines.






Fill RESBD Structure from EBP Component Structure   ABAP Short Reference  
This documentation is copyright by SAP AG.

Length: 19350 Date: 20240419 Time: 102240     sap01-206 ( 346 ms )