Skip to Content
Technical Articles

Easy way to sort an internal table in ascending & descending order both at the same time


In certain cases, you might need to sort an internal table in ascending & descending order both based on certain columns to achieve a particular output. SAP has already provided the solution quiet before. I am writing this blog post as I have come across a similar situation a few days back.


First of all, we should check the syntax of the SORT. Then a lit bit of theory.

SORT <itab> [<order>] [AS TEXT]
[BY <f1> [<order>] [AS TEXT]... <fn> [<order>] [AS TEXT]].


If the BY option is not used then, the internal table <itab> will be sorted by its standard key.

To define a different sort key, use the BY option. The system then sorts the dataset according to the specified components <f 1 >… <f n >. These fields can be of any type, including type P, I, and F fields, or tables. The options that you specify behind individual fields overwrite for these fields the options specified before BY.

If a sort criterion is not known until runtime, you can set it dynamically by writing (<name>) instead of <f i >. The field <name> contains the name of the sort key field. If <name> is empty at runtime, the system ignores it. If it contains an invalid component name, a runtime error occurs.

You can specify the sorting sequence by using DESCENDING or ASCENDING in the <order> option. The default is ascending.

Without the option AS TEXT, the system sorts character fields binarily and according to their platform-dependent internal coding. With the option AS TEXT, the system sorts character fields alphabetically according to the current text environment.

Stable keyword

It allows you to perform a stable sort, that is, the relative sequence of lines that are unchanged by the sort is not changed. If you do not use the STABLE option, the sort sequence is not preserved. If you sort a table several times by the same key, the sequence of the table entries will change in each sort. However, a stable sort takes longer than an unstable sort.

Now, please check the lines of code below for further reference.


Before sort

After sort


That’s it. 🙂

If you like this blog post, please like, share & comment.

Also, please don’t forget to endorse me on LinkedIn. 🙂

You must be Logged on to comment or reply to a post.
  • It is good to mention that you should use a sorted table when possible.

    I'm not aware of an option to define a key component with descending sort in a sorted table though.

  • Word of caution: because the order and BY additions are all optional, it's very easy to get confused and specify a wrong sort order. It's very important to follow the exact syntax (e.g. SORT ... DESCENDING BY...). I've seen more than one case where the developer got confused and assumed that in SORT... BY f1 DESCENDING f2 descending order applied to the field f1 (because that sounds like natural language) while it actually applied to the field f2 because of the syntax.

    It would be nicer if a better data example was included in the blog. With this specific example, we can't really confirm the result since there are not enough different value combinations.

    • Thanks, Jelena Perfiljeva for checking out my blog post. I agree with your comments regarding syntax.

      As I am using a sandbox, I don’t not having enough entries to show the different value combinations so, sorry for the same. In the future, I will try to provide more examples in my blog posts.

      • Just a suggestion: after SELECT, you could use debugger to add more entries to the internal table before sorting. Since this is only about sorting, it doesn't matter whether data is real or not.

    • For the matter of fact, I was in shock for a moment, so I had to double check it.

      However, it seems that the SORT syntax works as expected, i.e. the ASCENDING/DESCENDING applies on the field mentioned before it (SORT… BY f1 DESCENDING f2 descending order applied to the field f1)

    • I think the most frequent error made by developers is to position DESCENDING at the end, when they want to apply a descending order to all fields mentioned:

      SORT itab BY field1 field2 field3 DESCENDING.

      But that applies DESCENDING only to field3, and the others have the default ascending order (as correctly expressed in the blog post: "The system uses the options you specify before BY as a default for all fields specified behind BY", a sentence taken from the ABAP documentation when it was in the file 00000980.CHM, if old developers remember...)

      To apply a descending order to all the fields mentioned, the order has to be positioned before BY:

      SORT itab DESCENDING BY field1 field2 field3.
    1. You said that "The number of key fields is limited to 250", but it's incorrect.

      I did a test with 362 fields and it's okay. Same thing for defining the primary key of a sorted table, no limit.

      There's no limit indicated in the ABAP documentation. Be careful when you copy obscure references 😉

    2. You also mentioned that "These fields can be of any type, including [...] tables".

      The use case of sorting by sub-tables is extremely rare (I never saw that in programs). It has no interest in the sense of sorting in ascending or descending order, but it can be used to access quickly the line (binary search) which contains of a sub-table by its exact content.

      Strangely, it's permitted to access a standard table by its sub-table with READ TABLE BINARY SEARCH, but it's not possible to define a sub-table as part of a key of an internal table.