ABAPDELETE_ITAB_LINES - DELETE ITAB LINES

Addresses (Business Address Services)   PERFORM Short Reference  
This documentation is copyright by SAP AG.

DELETE itab - itab_lines

Short Reference

Syntax

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

Additions

1. ... USING KEY keyname

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

3. ... WHERE log_exp

4. ... WHERE (cond_syntax)

Effect

To delete several lines at once, you have to specify at least one of the additions FROM, TO, or WHERE. USING KEYkeyname is used to determine the table key to which the additions refer.

If you specify several of the additions, the rows are deleted that result from the intersection of the individual additions.

Addition 1

... USING KEY keyname

Effect

Using the USING KEY addition, a table key can be specified in keynamewith 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 asecondary 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.

Example

Refer to Deleting Rows Using A Key

Addition 2

... [FROM idx1] [TO idx2]

Effect

These additions have the effect that only table rows from row number idx1, or up to row numberidx2, are taken into account in the table index used. If only FROM is specified, all rowsof the table from row number idx1 up to and including the last row are taken into account. Ifonly 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 theprimary table key is specified in keyname, the additions FROM and TO can only be used forindex tables. In this case, they refer to the row numbers of theprimary table index.

If a sortedsecondarykey 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 thesecondary table index.

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

• If the value of idx1 is less than 0, it is set to 1 in the LOOP statement and causes aruntime 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 0, the LOOP statement is not carried out and in everyother 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.
  
  
  

Addition 3

... 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 acomponent of the internal table. You cannot specify apredicatefunction. The components of the internal table must be declared as individual operands and not aspart 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 anysuitable individual operands orcalculationexpressions, but not components of the internal table. All logical expressions are possible exceptfor the IS ASSIGNED,IS SUPPLIED,and obsolete IS REQUESTED predicates. The specified components can be of any data type. For evaluations, the relevantcomparison rules apply.

When standardtables 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 ahash key is used, that is, when asorted table, ahashed table, or asecondary table key is accessed, access is optimized in the following circumstances:

• If a sortedkey is declared, the logical expression uses comparisons linked with AND with the relationaloperator = (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 hashkey is declared, the logical condition uses comparisons linked with AND with the relationaloperator = (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 thecomparison rulesfor incompatible data types apply when incompatible data objects are compared, whereby the data typesinvolved determine which operand is converted. In contrast, when the WITHTABLE KEY and WITHKEY additions of the READ statements are used, the content of the specified data objectsis 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 READstatement 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 becompatiblein 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 selectiontable is specified after INas a logical expression, note that the expression for the initial table is always true and all rows are then processed.
  
  
  

Addition 4

... WHERE (cond_syntax)

Effect

Dynamic WHERE Condition cond_syntax can be specified as a character-like data object orstandardtable 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 internaltable, 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 classCX_SY_ITAB_DYN_LOOP.

The obsolete relational operators (><, =>, and =<) are not supported in cond_syntax.

Notes

• Of the calculation expressions, onlyarithmetic expressions are currently supported.String expressions andbit expressions are not supported.String functions andbit 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.
  
  
  

Example

Deletes all rows in an internal table from row 4. The result is the same as in the example for APPEND... SORTED BY. The column seatsfree is not needed by the SELECT statement, but is filled by the program. This is why the corresponding syntax check warning is suppressed by the appropriatepragma.

PARAMETERS: p_carrid TYPE sflight-carrid,
            p_connid TYPE sflight-connid.

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
       FROM sflight
       INTO TABLE seats_tab
       WHERE carrid = p_carrid AND
             connid = p_connid ##too_many_itab_fields.

LOOP AT seats_tab INTO seats.
  seats-seatsfree = seats-seatsmax - seats-seatsocc.
  MODIFY seats_tab INDEX sy-tabix FROM seats.
ENDLOOP.
ENDLOOP.

SORT seats_tab BY seatsfree DESCENDING.

DELETE seats_tab FROM 4.

ROGBILLS - Synchronize billing plans   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.


Length: 17429 Date: 20120522 Time: 050139     triton ( 431 ms )