ABAP開発

ABAPのSELECT-OPTIONSで大量指定するとショートダンプ？原因と対策

2019.10.08 2026.10.12

ABAPの選択画面で SELECT-OPTIONS に大量の値を貼り付けると、実行時にショートダンプが発生することがあります。原因は入力欄そのものとは限りません。プログラムがその選択条件を WHERE ... IN でデータベースへ渡したとき、SQL文の大きさやデータベースとの受け渡し制限に達する場合があります。

「何件以上なら必ずエラー」という共通の上限はありません。条件の行数だけでなく、値の長さ、EQ・BT・CP などの指定方法、ほかの条件、ABAPとデータベースの環境が影響します。S/4HANAやHANAでも発生例があるため、製品名だけで問題が解消したとは判断できません。

SELECT-OPTIONSの値がSQL条件になる仕組み

SELECT-OPTIONS は、SIGN、OPTION、LOW、HIGH を持つ選択テーブルを作ります。複数選択画面で入力した行は、このテーブルに格納されます。次のように IN 条件へ渡すと、その指定内容がデータベース検索に反映されます。

DATA gv_matnr TYPE mara-matnr.
SELECT-OPTIONS s_matnr FOR gv_matnr.

START-OF-SELECTION.
  DATA(lv_condition_rows) = lines( s_matnr[] ).

  SELECT matnr
    FROM mara
    WHERE matnr IN @s_matnr
    INTO TABLE @DATA(lt_matnr).

lv_condition_rows は入力した選択条件の行数です。lt_matnr の取得件数とは異なります。取得結果を UP TO ... ROWS や PACKAGE SIZE で制限しても、大量の入力条件をSQLへ渡す問題そのものは解消しません。また、選択テーブルが空なら絞り込みが外れる場合があるため、分割処理を設計するときは空テーブルを渡さないようにします。

ショートダンプが起きたらST22で原因を確認する

ST22でダンプを開く。 実行時エラー名、発生したプログラムと行、エラー解析欄を確認します。SQLが大きすぎる場合は DBSQL_STMNT_TOO_LARGE などが表示されることがありますが、名前だけで原因を決めつけないでください。
失敗したSQLと入力条件を照合する。 どの選択テーブルが IN に渡され、各テーブルに何行あったかを調べます。複数の条件を組み合わせている場合は、その全体を確認します。
必要に応じてSQLトレースを取る。 検証環境でST05などを使い、生成されたSQLや実行状況を確認します。本番環境では運用担当者と調整します。

メモリ不足、タイムアウト、型変換など、別の原因でもショートダンプは起こります。まずST22の記録を読むことが対策を選ぶ出発点です。

大量の選択条件を減らす・処理する方法

重複した同一条件を除く。 同じ I/EQ の値が繰り返し入力されているなら、意味を変えずに重複を取り除けます。
正しい範囲へまとめる。 連続する値を BT の範囲にできる場合は条件行を減らせます。ただし、番号の間に対象外の値が含まれないことを業務上確認してください。
ほかの絞り込み条件を使う。 日付、会社コード、組織などで対象を先に狭められるなら、必要な個別値の数も減らせる場合があります。
大量の個別キーは設計を見直す。 単純な I/EQ の一覧なら、検証済みの件数ごとに取得して結果を統合する方法があります。分割件数に普遍的な安全値はないため、対象環境で測定します。

選択テーブルを機械的に分割してはいけません。 除外条件 E、範囲 BT、パターン CP を含む場合は、分割前後で検索結果が同じになるとは限りません。分割取得では重複結果の扱い、空の条件、ほかの検索条件、総取得件数も確認します。FOR ALL ENTRIES へ置き換える場合も、空の内部テーブルなど固有の注意点があるため、安易な置換は避けます。詳しくはFOR ALL ENTRIESの空テーブル・重複・JOINとの使い分けを参照してください。