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)} = dobj1 

                     {comp_name2|(name2)} = dobj2 

              
      ...                           } ... . 

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.

Notes

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 lines to be deleted are found quickly, a linear search must be carried out for the entry to be deleted when the primary index is updated.

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 a standard table is accessed using the primary table key and this is empty, the first row of the internal table is deleted.

Notes

• When using the primary table key, note that this may also by the standard key, whereby unexpected effects may occur:
  

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

• The standard key of a standard table may be empty.

• Outside of classes, an obsolete short form still exists for which you can omit the FROM wa specification if the internal table has an identically named header line (itab). The statement then uses the header line as the work area implicitly. Without FROM wa, USING KEY cannot be specified.
  

Example

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

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 blank spaces, this component specification is ignored in the execution of the statement. A data object dobj1 dobj2 ..., which is compatible with the data type of the component or that can be converted 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 data object dobj1 dobj2 ... assigned, is processed. If necessary, the content of dobj1 dobj2 ... is converted to the data type of the component before the comparison. No duplicate or overlapping key declarations can be made.

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 data objects dobj1 dobj2 ... 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, dobj1 dobj2 ... must be compatible with the data type of the component.
• A Customizing include must not be specified as a component if it is empty.
  

Example

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

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. 

This translation does not reflect the current version of the documentation.