FOR ALL ENTRIES with an empty table: the trap and the fix

By ABAP for Agents · Updated 22 October 2026

FOR ALL ENTRIES is one of the most common patterns in classic ABAP: read some keys into an internal table, then fetch the matching rows from the database in one statement. It is also behind a whole class of production incidents, because of one documented rule that is easy to forget.

The trap

Here is code an AI assistant (or a tired developer) writes every day:

SELECT vbeln, posnr, matnr, netwr
  FROM vbap
  FOR ALL ENTRIES IN @orders
  WHERE vbeln = @orders-vbeln
    AND erdat >= @date_from
  INTO TABLE @DATA(items).

It activates, the syntax check is happy, and in a test with a few orders it returns exactly what you expect. Now imagine orders is empty because an earlier selection found nothing.

SAP's ABAP Keyword Documentation is explicit: if the internal table is empty, the entire WHERE condition is ignored. No row of the database table is skipped. That includes erdat >= @date_from, which has nothing to do with the internal table. The statement reads every item in VBAP for the current client.

On a development system with a few hundred rows, nobody notices. In production it can mean a very long runtime, a memory dump, or worse, a program that silently processes every document in the system.

The fix: guard the driver table

The fix is one IF:

IF orders IS NOT INITIAL.
  SELECT vbeln, posnr, matnr, netwr
    FROM vbap
    FOR ALL ENTRIES IN @orders
    WHERE vbeln = @orders-vbeln
      AND erdat >= @date_from
    INTO TABLE @DATA(items).
ENDIF.

A few practical points:

• Put the guard directly around the SELECT. A check twenty lines earlier stops protecting you as soon as someone adds a DELETE in between.
• Decide what "empty" means for the caller. If the SELECT is skipped, the target table stays as it was. That's usually what you want, but if the code runs in a loop, clear the target first so old rows don't leak into the next pass.
• Remove duplicate keys from the driver. Sorting the driver and deleting adjacent duplicates keeps the generated database statements smaller:

SORT orders BY vbeln.
DELETE ADJACENT DUPLICATES FROM orders COMPARING vbeln.

The second trap: duplicate rows disappear

The same documentation page says that FOR ALL ENTRIES removes rows that occur more than once in the result set, considering the entire content of the row. It behaves like SELECT DISTINCT.

That's harmless when you select the full primary key. It's a silent data bug when you don't:

" Wrong: no POSNR, so two items with the same net value collapse into one
SELECT vbeln, netwr
  FROM vbap
  FOR ALL ENTRIES IN @orders
  WHERE vbeln = @orders-vbeln
  INTO TABLE @DATA(values).

If an order has two items worth 100.00 each, values contains one row, and any total you compute from it is wrong. Add the key field and the problem goes away:

SELECT vbeln, posnr, netwr
  FROM vbap
  FOR ALL ENTRIES IN @orders
  WHERE vbeln = @orders-vbeln
  INTO TABLE @DATA(values).

Rule of thumb: with FOR ALL ENTRIES, always select all key fields of the table you read.

Other restrictions worth knowing

FOR ALL ENTRIES doesn't combine freely with the rest of ABAP SQL. According to the keyword documentation:

• It can't be used with SELECT SINGLE.
• Aggregate expressions other than COUNT( * ) aren't allowed in the SELECT list, and GROUP BY has no effect.
• ORDER BY is only possible as ORDER BY PRIMARY KEY, for a single table or view.
• It can't be combined with UNION, INTERSECT or EXCEPT.

These are exactly the details an AI assistant tends to get wrong, because they only show up in the documentation, not in typical example code.

A related trap: empty ranges tables

Ranges tables have a similar rule. The documentation for IN range_tab says that if the ranges table is initial, the expression is always true. With no other conditions, every row is selected:

" If material_range is initial, this reads all of MARA
SELECT matnr, mtart
  FROM mara
  WHERE matnr IN @material_range
  INTO TABLE @DATA(materials).

That is often intended for selection-screen input (an empty select-option means "no restriction"). It's a bug when the range is built in code from a list that turned out to be empty. Guard it the same way, and keep in mind that very large ranges tables can exceed the database's limit on input values, which raises CX_SY_OPEN_SQL_DB.

Alternatives to FOR ALL ENTRIES

FOR ALL ENTRIES isn't wrong: the documentation notes that it can use table buffering and can be more efficient than a join in some cases. But it's not your only option:

• A join or subquery, when the keys come from another database table anyway. One statement, no driver table, no empty-table trap.
• An internal table as a data source (SELECT ... FROM @itab), available from 7.52. Check the keyword documentation for your release and database before relying on it in a join.
• A CDS view, on S/4HANA, when the same combination of tables is read in several places.

Whichever you choose, avoid the worst option: a SELECT SINGLE inside a LOOP.

Why AI assistants get this wrong

Language models learn from public code, and a lot of public ABAP uses FOR ALL ENTRIES without a guard because the guard sits somewhere else, or because the example was never run on an empty table. The model reproduces the pattern without the context.

The reliable fix is to state the rule where the assistant reads it on every request: "Always guard FOR ALL ENTRIES with IF itab IS NOT INITIAL, and select all key fields." Our free lite rules include it in the ABAP SQL rule, together with strict-mode @ escaping and the SELECT SINGLE full-key rule. For more of these patterns, see ABAP mistakes AI coding assistants make.

As always, rules reduce repeat mistakes but don't replace review. An ATC run and a unit test with an empty driver table will catch this bug before it reaches production.

More guides