3

What exactly does the SORT statement without key specification do when run on a standard internal table? As per the documentation:

If no explicit sort key is entered using the addition BY, the internal table itab is sorted by the primary table key. The priority of the sort is based on the order in which the key fields are specified in the table definition. In standard keys, the sort is prioritized according to the order of the key fields in the row type of the table. If the primary table key of a standard table is empty, no sort takes place. If this is known statically, the syntax check produces a warning.

With the primary table key being defined as:

Each internal table has a primary table key that is either a self-defined key or the standard key. For hashed tables, the primary key is a hash key, for sorted tables, the primary key is a sorted key. Both of these table types are key tables for which key access is optimized and the primary key thus has its own administration. The key fields of these tables are write-protected when you access individual rows. Standard tables also have a primary key, but the corresponding access is not optimized, there is no separate key administration, and the key fields are not write-protected.

And for good measure, the standard key is defined as:

Primary table key of an internal table, whose key fields in a structured row type are all table fields with character-like data types and byte-like data types. If the row type contains substructures, these are broken down into elementary components. The standard key for non-structured row types is the entire table row if the row type itself is not a table type. If there are no corresponding table fields, or the row type itself is a table type, the standard key from standard tables is empty or contains no key fields.

All of which mainly just confuses me as I'm not sure if I can really rely on the basic SORT statement to provide a reliable or safe result. Should I really just avoid it in all situations or does it have a purpose if used properly?

By extension, if I want to run a DELETE ADJACENT DUPLICATES FROM itab COMPARING ALL FIELDS, when would it be safe to do so after a simple SORT itab.? Only if I added a key on all fields? Without an explicit key only if I have an internal table with clike and xsequence columns? If I want to execute that DELETE statement, what is the most optimal SORT statement to run on the internal table?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
Lilienthal
  • 4,327
  • 13
  • 52
  • 88

2 Answers2

6

SORT without BY should be avoided in all situations because it "makes the program difficult to understand and possibly unpredictable" (dixit ABAP documentation). I think that if you don't mention BY, there is a warning by a static check in the Code Inspector. You should use SORT itab BY table_line where table_line is a special name ("pseudo-component") meaning "all fields of the line".

Not your question, but you may also define the internal table with primary and secondary keys, so that you don't need to sort explicitly - DELETE ADJACENT DUPLICATES can be used with any of those keys.

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
  • 2
    And another thought: tables that consist of one column only can safely ignore the BY clause. There is no space for interpretation in this case. Tables like that often appear in BOPF where you often work with “lists” of GUIDs that identify nodes in business objects. – Florian Oct 26 '18 at 06:34
  • @András The official sentence better justifies it: ["It is best to specify an explicit sort key behind BY, if possible. An implicit sort behind the primary table key (which can itself, in standard tables, be defined implicitly as a standard key) makes a program difficult to understand and possibly unpredictable."](https://help.sap.com/http.svc/rc/abapdocu_752_index_htm/7.52/en-US/index.htm?file=abapsort.htm) – Sandra Rossi Dec 04 '18 at 14:59
0

Internal tables can have keys that can be inherited from structures the itab is based on or specified. As the documentation says, sort without by sorts by primary key, and that is safe assuming the internal table is implemented correctly.

I think this feature is designed as a dynamic feature to be used with smart table key design. If done correctly, sort without by can get your program to adapt to table key changes in the future. (so if your key changes, sort with change with it). Problems might arise when key is modified in an odd way.

As rule of a thumb:

The more specific your program code is, the less prone to errors (and safer) it is. So sort by key_id, key_date will always produce the same sort by those 2 fields.

Dynamic components in an application make it more flexible, but tend to have (often hard to notice) bugs coming out when things they rely on are modified . So if you take the previous example with 2 key fields, you add 1 in the middle (let's say key_is_active between 2 existing fields), sorting results might change in a way you did not expect. If you had an algorithm that processes based on date, your algorithm might be broken by that change.

In your particular case with delete adjacent I would follow Sandra Rossi's advice.

Zero
  • 1,562
  • 1
  • 13
  • 29