ABAP SORT Statement is strange

[former_member591443]

Hi everyone,

I am facing with a strange issue about sorting.

My data before sorting is below:

After using "SORT itab BY EBELP ETENR RSPOS, the output is strange:

As you can see above, I don't know why "I" go before "D" in RSPOS item no 10.

Can everyone help me explain the reason why I > D?.

I think that it should be keep the original order in case of the sort key is the same.

(NOTE: The sort statement is in BAPI_PO_CHANGE)

[Dominik_Tylczynski]

I guess you missed screen shots with the data before and after sort. Showing the itab internal table definition would also help to help you.

[sergey_muratov]

Hi

These two example rows have same key on level EBELP+ETENR+RSPOS. So order in other columns will be random.

[former_member591443]

Thank for your answer,

But, why other lines alway keep the original order(D>I). Only item RSPOS 10 have I>D

[former_member591443]

@3a9e4ce873a94034b33dc62b0ce600ee

I edited it from 5 minute ago. On my screen, the picture display correctly.

[VXLozano]

Are you kiddin'?

If you are sorting by EBELP, ETENR and RSPOS, the data appears sorted by those three fields. The column you marked as "weird" is UPDKZ. It's not sorted (and must NOT be).

Check again your screenshots, and take a deeper look at the column RSPOS.

Before the SORT you have something like

• 10 - D
• 20 - D
• 10 - I
• 20 - I

and after the sort, the RSPOS are rearranged (and thus, the UPDKZ disordered)

• 10 - D
• 10 - I
• 20 - D
• 20 - I

Nothing weird at all, mate.

[former_member591443]

Hi @vicen.lozano,

The weird thing is :

10-I

10-D

20-D

20-I

Because I think SORT statement should keep the original order in case of the same key

[VXLozano]

You are wrong by assuming things. That attitude lead a lot of developers to not use the ORDER BY in a lot of programs, and when their companies moved to HANA DB, all those programs stopped to work properly, because HANA gives the data unsorted.
NEVER EVER assume anything.

If you tell SAP to SORT BY col_list, do not expect for it to sort the other columns. Maybe it does, but it will stop doing it at any time.

[former_member591443]

vicen.lozano

Thank for your information,

My purpose in this question is that I want to understand more about the logic in SORT statement to find solution because the sort statement above is in Standard program(Which I don't want to change).

[VXLozano]

Mate, check my answer and once you get it, ask this post to be deleted to not be read again in the future (ie, when someone will search by "SORT").

Thanks in advance.

[Dominik_Tylczynski]

Hello kemdau

What you are see is perfectly normal - see SAP Help on SORT itab. It reads:

Sorting is unstable by default, which means that the relative order of rows that do not have different sort keys is not preserved when they are sorted. The order can be different depending on the platform or when sorted multiple times. The addition STABLE can be used for stable sorting.

If you need to preserve the relative order of rows after sorting, use STABLE.

Best regards

Dominik Tylczynski

[VXLozano]

Never knew abot that STABLE thing.

I will try to forget ASAP (when I need any kind of sorting, I specify the whole sort and I don't care about the rest of the columns). Check my comment about assumptions in my answer.

But if some day I see that STABLE thing, I will not think about horses nor donkeys XD

[LaurensDeprost]

Hi,

This behaviour can be considered normal in ABAP. That said, I think it poses an interesting question on the inner workings of SORT. To explain this behavior with 100% certainty, we would need to know the exact implementation of the SORT statement in ABAP.

My guess:
The 'plain' SORT statement uses the some kind of quicksort algorithm. From Wikipedia: "Quicksort is a divide-and-conquer algorithm. It works by selecting a 'pivot' element from the array and partitioning the other elements into two sub-arrays, according to whether they are less than or greater than the pivot."

So in your example, my assumption is the middle element, meaning line 12, is chosen as the first pivot. This explains the strange behavior that you see: the first element has UPKZ 'I', while all following rows occur in their 'original' order, with UPKZ 'D' before 'I'.

[former_member591443]

Hi dep

Thank you so much,

[former_member591443]

Hi vicen.lozano,

I think this post should be keep.