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

[Former Member]

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

[Former Member · Accepted solution]

Hi,

I have answered this myself. I thought that the sort of records within the group reflects the order of the appended records:

APPEND 'DC' TO lt.  "#1 in group 2 by key K1 (value C)
APPEND 'BB' TO lt.  "#1 in group 1 by key K1 (value B)
APPEND 'AC' TO lt.  "#2 in group 2 by key K1 (value C)

but this is not the case. The order in the internally maintained secondary index K1 is built somehow 'backwards', so that if I append the records in different order

APPEND 'AC' TO lt.

APPEND 'BB' TO lt.

APPEND 'DC' TO lt.

then the result of DELETE ADJACENT DUPLICATES in previous example is:

BB

DC

as you see, the system considered record DC to be the first in the group now and preserved it while AC was deleted. This means that non-key fields are NOT considered while building the secondary index order and it also shows that the records with the same key field values are stored in the secondary index internally in different order than being appended.

Conclusion: be careful when using DELETE ADJACENT DUPLICATES using secondary keys as it can result in different result than expected - or better: have the values for all fields specified when deleting the records 🙂

Closing the thread.

Michal