Внутренние таблицы могут иметь ключи, которые могут быть унаследованы от структур, на которых основана или указана itab.Как сказано в документации, sort без by сортируется по первичному ключу и что является безопасным при условии, что внутренняя таблица реализована правильно.
I думаю этоЭта функция разработана как динамическая функция, которая будет использоваться с ключом смарт-таблицы .Если все сделано правильно, sort без by может заставить вашу программу адаптироваться к изменениям ключа таблицы в будущем.(так что если ваш ключ меняется, сортируйте с изменением вместе с ним).Проблемы могут возникнуть, когда ключ модифицируется нечетным образом.
Как правило:
Чем конкретнее код вашей программы, тем менее он подвержен ошибкам (и безопаснее).Таким образом, sort by key_id, key_date всегда будет производить одинаковую сортировку по этим двум полям.
Динамические компоненты в приложении делают его более гибким, но, как правило, имеют (часто трудно заметить) ошибки, возникающие, когда они полагаются намодифицированныйПоэтому, если вы возьмете предыдущий пример с 2 ключевыми полями, вы добавите 1 в середине (скажем, key_is_active между 2 существующими полями), результаты сортировки могут измениться так, как вы этого не ожидали.Если у вас есть алгоритм, который обрабатывает на основе даты, ваш алгоритм может быть нарушен этим изменением.
В вашем конкретном случае с delete adjacent Я бы следовал совету Сандры Росси .