0

So far, I always used this to get specific lines from an internal table:

LOOP AT it_itab INTO ls_itab WHERE place = 'NEW YORK'.
    APPEND ls_itab TO it_anotherItab
    INSERT ls_itab INTO TABLE it_anotherItab
ENDLOOP.

However, with 7.40 there seems to be REDUCE, FOR, LINES OF and FILTER. FILTER requires a sorted or hashed key, which isn't the case in my example. So I guess only FOR comes into question.

DATA(it_anotherItab) = VALUE t_itab( FOR wa IN it_itab WHERE ( place = 'LONDON' )

                         ( col1 = wa-col2 col2 = wa-col3 col3 = ....... ) ).

The questions are:

  • Are both indeed doing the same? Is the 2nd one an APPEND or INSERT?
  • Is it possible in the second variant to use the whole structure and not specifying every column? Like just ( wa )
  • Is the second example faster?
Suncatcher
  • 10,355
  • 10
  • 52
  • 90
Regyn
  • 585
  • 3
  • 17
  • `REDUCE` doesn't seem to solve the problem you are facing here. Why aren't you able to use `FILTER`? You just have to extend your tables type by a second key btw. –  Jun 15 '17 at 10:05
  • @lausek But place isn't a unique key in my case, nor is it_itab a SORTED TABLE. Imagine I want to get all entries from an internal table (STANDARD TABLE OF) where place is London. – Regyn Jun 15 '17 at 11:23
  • Does this answer your question? [Most efficient itab filtering with ABAP 7.40+ syntax](https://stackoverflow.com/questions/48825937/most-efficient-itab-filtering-with-abap-7-40-syntax) – Suncatcher Oct 21 '20 at 13:44

1 Answers1

2

In accordance to your comment, you can also define a sorted secondary key on a standard table. Just look at this example here:

TYPES:
    BEGIN OF t_line_s,
        name1 TYPE name1,
        name2 TYPE name2,
        ort01 TYPE ort01,
    END OF t_line_s,

    t_tab_tt TYPE STANDARD TABLE OF t_line_s
        WITH NON-UNIQUE EMPTY KEY
        WITH NON-UNIQUE SORTED KEY place_key COMPONENTS ort01. "<<<

DATA(i_data) = VALUE t_tab_tt( ). " fill table with test data

DATA(i_london_only) = FILTER #( 
    i_data 
    USING KEY place_key  " we want to use the secondary key
    WHERE ort01 = CONV #( 'london' ) " stupid conversion rules...
).

" i_london_only contains the filtered entries now

UPDATE:
In my quick & dirty performance test, FILTER is slow on first call but beats the LOOP-APPEND variant afterwards.

UPDATE 2:
Found the reason today...

... the administration of a non-unique secondary table key is updated at the next explicit use of the secondary table key (lazy update).