ABAP Keyword Documentation → ABAP - Reference → Processing Internal Data → Internal Tables → Processing Statements for Internal Tables → DELETE itab → DELETE itab - itab_line

DELETE itab - table_key

Short Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax


... { FROM wa [USING KEY keyname] } 

  | { WITH TABLE KEY [keyname COMPONENTS] 

                     {comp_name1|(name1)} = operand1 

                     {comp_name2|(name2)} = operand2 

              
      ...           
                 } ...

Alternatives

1. ... FROM wa [USING KEY keyname]

2. ... WITH TABLE KEY [keyname COMPONENTS] ...

Effect

Specifying a Table Key as a Search Key Either the primary table key or a secondary table key can be specified. The values can be declared either implicitly in a work area wa behind FROM or by listing the components of the table key explicitly behind TABLE KEY.

When the primary table key is used, the table categories are accessed as follows:

Standard tables are searched in a linear fashion.
Binary scans are used for sorted tables.
The hash algorithm is used for hashed tables.

When the secondary table key is used, a binary scan is used in the sorted key case and a hash algorithm is used in the hash key case.

Note

When deleting a row from a standard table using a secondary key, the entire runtime depends linearly on the number of table rows. Although the rows to be deleted are found quickly, when updating the primary index a linear search for the entry to be deleted must be carried out.

Alternative 1

... FROM wa [USING KEY keyname]

Effect

For wa, a work area compatible to the row type of the internal table must be specified. This concerns functional operand positions. The first row of the internal table found, whose values in the columns of the table key used match those of the corresponding components of wa, is processed. If the key fields in wa are empty, no entries are processed.

If the USING KEY addition is not specified, the primary table key is used. If the USING KEY addition is specified, the table key specified in keyname is used.

If the primary table key is used to access a standard table and the key is empty, then the first row of the internal table is deleted. If this is statically identifiable, the syntax check produces a warning.

Notes

When using the primary table key, note that this key can be the standard key, which can also have unexpected consequences:

For structured row types, the standard key covers all character-like and byte-like components.

The standard key of a standard table can be empty.

Outside of classes, an obsolete short form is also 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 USING KEY.

Example

A work area scarr_wa is used to delete the table row that has the same value as p_carrid in the key field carrid of the primary table.

PARAMETERS p_carrid TYPE scarr-carrid. 

DATA: scarr_tab TYPE SORTED TABLE OF scarr 
               WITH UNIQUE KEY carrid, 
      scarr_wa  LIKE LINE OF scarr_tab. 

SELECT * 
       FROM scarr 
       INTO TABLE @scarr_tab. 

IF sy-subrc = 0. 
  scarr_wa-carrid = p_carrid. 
  DELETE TABLE scarr_tab FROM scarr_wa. 
ENDIF.

Alternative 2

... WITH TABLE KEY [keyname COMPONENTS] ...

Effect

Each component of the table key used must be listed either directly as comp_name1 comp_name2 ... or as a parenthesized character-like data object name1 name2 ..., which contains the name of the component when the statement is executed. name is not case-sensitive. If name only contains blanks, this specified component is ignored when the statement is executed. An operand operand1 operand2 ... compatible with the data type of the component or convertible to it must be assigned to every component. The first row of the internal table found, whose values in the column of the table key used correspond with the values in the operands operand1 operand2 ... assigned, is processed. Duplicate or overlapping keys cannot be specified, nor can columns be specified that are not components of the table key.

operand1 operand2 ... are general expression positions. If necessary, the content of the operands is converted to the data type of the components before the comparison. If an arithmetic expression is specified, the calculation type is determined from its operands and the data type of the component and the result, if necessary, is converted to the data type of the component.

If the addition COMPONENTS is not specified, the primary table key is used. If the addition COMPONENTS is specified, the table key specified in keyname is used.

Notes

The pseudo component table_line can be specified as a component for tables with an unstructured row type, if their whole table entry is defined as a table key.
If WITH TABLE KEY is used, note that the values of incompatible operands operand1 operand2 ... are converted to the data type of the columns before the comparison. This means that the comparison rules do not apply to incompatible data types. If a WHERE condition is used in the statements LOOP, MODIFY, and DELETE, however, the comparison rules do apply, which can produce differing results.
To avoid unexpected results after a conversion, operand1 operand2 ... must be compatible with the data type of the component.
If the row type of the internal table cannot be statically identified, the components of the key can only be specified dynamically and not directly.
A Customizing include must not be specified as a component if it is empty.

Example

By explicitly declaring the primary table key, the table row is deleted that has the same value as p_carrid in the key field carrid.

PARAMETERS p_carrid TYPE scarr-carrid. 

DATA scarr_tab TYPE SORTED TABLE OF scarr 
              WITH UNIQUE KEY carrid. 

SELECT * 
       FROM scarr 
       INTO TABLE @scarr_tab. 

DELETE TABLE scarr_tab WITH TABLE KEY carrid = p_carrid.