問題タブ [internal-tables]

SORT標準内部テーブルで実行すると、キー指定のないステートメントは正確に何をしますか? ドキュメントに従って：

オプション BY を使用して明示的なソートキーが入力されていない場合、内部テーブル itab は一次テーブルキーによってソートされます。ソートの優先順位は、テーブル定義でキー フィールドが指定されている順序に基づきます。標準キーでは、テーブルの行タイプのキー フィールドの順序に従って並べ替えが優先されます。標準テーブルの主テーブル キーが空の場合、並べ替えは行われません。これが静的にわかっている場合、構文チェックで警告が生成されます。

主テーブル キーは次のように定義されています。

各内部テーブルには、自己定義キーまたは標準キーの主テーブル キーがあります。ハッシュされたテーブルの場合、主キーはハッシュ キーであり、並べ替えられたテーブルの場合、主キーは並べ替えられたキーです。これらのテーブル タイプはどちらも、キー アクセスが最適化されているキー テーブルであり、主キーには独自の管理機能があります。これらのテーブルのキー フィールドは、個々の行にアクセスするときに書き込み保護されています。標準テーブルにも主キーがありますが、対応するアクセスは最適化されておらず、個別のキー管理はなく、キー フィールドは書き込み保護されていません。

また、標準キーは次のように定義されています。

内部テーブルの主テーブルキー。構造化された行タイプのキー項目はすべて、文字に似たデータ型とバイトに似たデータ型を持つすべてのテーブル項目です。行タイプにサブ構造が含まれている場合、これらは基本コンポーネントに分割されます。非構造化行タイプの標準キーは、行タイプ自体がテーブル タイプでない場合、テーブル行全体です。対応するテーブル フィールドがない場合、または行タイプ自体がテーブル タイプである場合、標準テーブルの標準キーは空であるか、キー フィールドが含まれていません。

SORT信頼できる、または安全な結果を提供するために基本的なステートメントに本当に依存できるかどうかわからないため、これらすべては主に私を混乱させるだけです. 本当にすべての状況でそれを避けるべきですか、それとも適切に使用すれば目的がありますか?

ひいては、 を実行したい場合DELETE ADJACENT DUPLICATES FROM itab COMPARING ALL FIELDS、単純な の後に安全に実行できるのはいつSORT itab.ですか? すべてのフィールドにキーを追加した場合のみですか? clikeおよびxsequence列を持つ内部テーブルがある場合にのみ、明示的なキーなしで? その DELETE ステートメントを実行したい場合、内部テーブルで実行するのに最適な SORT ステートメントは何ですか?

現在、私はこのコーディングを行っており、完全に正常に動作します:

新しい構文で同じことをしたいのですが、可能ですか?
はいの場合、どのように？