Skip to Content
0
Former Member
Mar 10, 2015 at 11:01 AM

ITAB secondary index: non-key fields considered as well! Bug or feature?

81 Views

Hi,

it looks like also non-key fields (i.e. fields not specified as components of secondary key) are taken into account when the system builds the order of the secondary index records. Let's assume following simplistic example:

TYPES:
BEGIN OF ts,
a,
b,
END OF ts.
DATA:
lt TYPE STANDARD TABLE OF ts WITH NON-UNIQUE SORTED KEY k1 COMPONENTS b.

FIELD-SYMBOLS: <lt> LIKE LINE OF lt.

APPEND 'DC' TO lt.
APPEND 'BB' TO lt.
APPEND 'AC' TO lt.

LOOP AT lt ASSIGNING <lt>.
WRITE:/ <lt>-a, <lt>-b.
ENDLOOP.

SKIP.

DELETE ADJACENT DUPLICATES FROM lt USING KEY k1.

LOOP AT lt ASSIGNING <lt>.
WRITE:/ <lt>-a, <lt>-b.
ENDLOOP.


In my opinion, the records should be maintained in secondary index K1 internally in the following sequence:

BB

DC

AC


which means that the first records of the groups formed on K1 index should be

BB

DC


and the record

AC


should be deleted (DELETE ADJACENT DUPLICATES always keeps only the first record in the group). However, the output of the program is

BB

AC


which probably means that the K1 internal order was

BB

AC

DC


which means that also non-key field A was taken into account. Do you know whether this is something we can rely on or is this something kernel or OS dependent?


Thank you

Michal