DELETE itab, itab_lines - ABAP Keyword Documentation

ABAP - Keyword Documentation → ABAP - Programming Language → Processing Internal Data → Internal Tables (itab) → itab - Processing Statements → DELETE itab →

Mail Feedback

DELETE itab, itab_lines

Short Reference

Syntax

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

The addition USING KEY can be used to specify a table key in keyname with which the processing is executed. The specified table key affects the order in which the table lines are accessed, and the evaluation of the remaining conditions.

If the primary table key is specified, the processing behaves in the same way as if no key were explicitly specified. If a secondary table key is specified, the order in which the lines are accessed is as follows:

Specification of a sorted key
The lines are processed by ascending line number in the secondary table index
Specification of a hash key
The lines are processed in the order in which they were inserted into the table.

Hints

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.

Example

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.

DATA itab TYPE TABLE OF i WITH EMPTY KEY
WITH UNIQUE SORTED KEY skey COMPONENTS table_line.

itab = VALUE #( ( 6 ) ( 5 ) ( 4 ) ( 3 ) ( 2 ) ( 1 ) ).

DELETE itab USING KEY skey FROM 4.

Addition 2

... [FROM idx1] [TO idx2]

Effect

These optional additions have the effect that only table rows from row number idx1 or up to and including row number idx2 are respected in the table index used. The table index used is either the primary index or a secondary sorted index specified by USING KEY.

If only FROM is specified, all lines of the table from line number idx1 up to and including the last line are respected. If only TO is specified, all lines in the table from the first line up to line number idx2 are respected.

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 and refer to the line 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 categories and refer to the line numbers of the secondary table index.

idx1 and idx2 are numeric expression positions of operand type i.

The following restrictions apply:

If the value of idx1 is less than or equal to 0, a runtime error occurs. If the value of idx1 is greater than the total number of table lines, no processing takes place.
If the value of idx2 is less than or equal to 0, a runtime error occurs. If the value of idx2 is greater than the number of table lines, it is set to the number of table lines.
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.

Hint

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.

DATA: carrid TYPE sflight-carrid VALUE 'LH',
      connid TYPE sflight-connid VALUE '0400'.
cl_demo_input=>new(
  )->add_field( CHANGING field = carrid
  )->add_field( CHANGING field = connid )->request( ).

DATA: BEGIN OF seats,
        fldate    TYPE sflight-fldate,
        seatsocc  TYPE sflight-seatsocc,
        seatsmax  TYPE sflight-seatsmax,
        seatsfree TYPE sflight-seatsocc,
      END OF seats.

DATA seats_tab LIKE STANDARD TABLE OF seats.

SELECT fldate, seatsocc, seatsmax, seatsmax - seatsocc AS seatsfree
       FROM sflight
       WHERE carrid = @carrid AND
             connid = @connid
       INTO TABLE @seats_tab.

SORT seats_tab BY seatsfree DESCENDING.
DELETE seats_tab FROM 4.

cl_demo_output=>display( seats_tab ).

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.

Hints

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.

SELECT *
       FROM spfli
       ORDER BY carrid
       INTO TABLE @DATA(itab).

DELETE itab FROM 1 TO 8 STEP 2.

cl_demo_output=>display( itab ).

Exceptions

Uncatchable 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 lines are processed for which the condition after WHERE is met. If a static WHERE condition is specified, the line 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:

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. 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 corresponding 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 specification, the access is not optimized. This means that all lines of the internal table are checked 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, the compiler tries to optimize the access as described under Optimization of the WHERE Condition. The prerequisites are:
- The entire logical expression or a part of it can be transformed into a key access.
- The transformable part of the logical expression has the same result as the resulting key access.
If an optimization is not possible, the behavior is as follows:
- If a sorted table or a hashed table is accessed using the primary table key, the full WHERE condition is applied to all lines of the table.
- If the table is accessed using a secondary table key, a syntax error or an exception is raised.

Hints

When using a WHERE condition, it should be noted 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 corresponding 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, which can produce varying results.
The difference between comparison rules in a WHERE condition and conversion rules when reading individual lines is particularly significant for enumerated types for which the comparison rules are more restrictive than conversion rules. Conversions of an enumerated object to a character-like type produce a message from the extended program check.
If possible, all operands of the logical expression should be in compatible pairs, so that the WHERE condition can be optimized.
If a comparison expression with a ranges table is specified after IN as a logical expression, the expression for the initial table is always true and then all lines are then processed.
Optimizations of the WHERE condition affect searches for the lines to delete but do not affect, for example, updates of the primary index of a standard table.

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.

DATA spfli_tab TYPE SORTED TABLE OF spfli
     WITH UNIQUE KEY carrid connid
     WITH NON-UNIQUE SORTED KEY skey COMPONENTS cityfrom cityto.

SELECT *
       FROM spfli
       INTO TABLE @spfli_tab.

DELETE spfli_tab WHERE carrid = 'LH' AND
                       connid = '0400'.

DELETE spfli_tab USING KEY skey WHERE cityfrom = 'FRANKFURT' AND
                                      cityto   = 'NEW YORK'.

Executable Example

Deleting Lines Using WHERE

Addition 5

... WHERE (cond_syntax)

Effect

Dynamic WHERE condition. For cond_syntax any character-like data object or standard table with character-like line type can be specified 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 lines. 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 Hint

If used incorrectly, 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 it is used in dynamic statements. This can be done using the system class CL_ABAP_DYN_PRG or the built-in function escape. See Security Risks Caused by Input from Outside.

Hint

The dynamic WHERE condition is not evaluated for an empty table for optimization reasons. Therefore, if an internal table is empty, and a logical expression has errors, no exception is raised.

Example

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

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

DATA itab TYPE TABLE OF i WITH EMPTY KEY
               WITH NON-UNIQUE SORTED KEY skey COMPONENTS table_line.

FINAL(t) = CONV i( cl_demo_date_time=>get_utc_time( ) ).
FINAL(rnd) = cl_abap_random_int=>create( seed = t
                                         min  = 1
                                         max  = 20 ).

itab = VALUE #( FOR i = 1 UNTIL i > 100
                ( rnd->get_next( ) - 10 ) ).
TRY.
    DELETE itab USING KEY skey WHERE (condition).
    cl_demo_output=>display( itab ).
  CATCH cx_sy_itab_dyn_loop INTO FINAL(exc).
    ...
ENDTRY.

Continue

itab - Deleting Lines Using WHERE