top of page
Search

FOR ALL ENTRIES: When a Performance Optimization Turns into a Performance Issue

Introduction


In SAP ABAP development, FOR ALL ENTRIES (FAE) is one of the most well-known techniques for performance optimization. Its main purpose is to eliminate repetitive database access inside loops and to reduce the number of database round trips. For this reason, it is often assumed to be faster by default.

However, in real-life scenarios, FOR ALL ENTRIES does not always improve performance. When it is used without proper checks, data volume analysis, or consideration of alternative solutions, it can lead to heavy SQL statements, inefficient index usage, and even full table scans.

This article explains why FOR ALL ENTRIES is considered a performance-friendly structure and highlights the most common mistakes that turn it into a performance pitfall, supported by practical examples. The goal is not to discourage its usage, but to promote correct and conscious implementation.



Why FOR ALL ENTRIES Is Expected to Improve Performance


The main goals of FOR ALL ENTRIES are:

  • To remove SELECT statements from loops

  • To minimize database access

  • To reduce network and round-trip time

A typical example that developers try to optimize is shown below:


LOOP AT gt_vbeln INTO gs_vbeln.
SELECT SINGLE * FROM vbak INTO gs_vbak
WHERE vbeln = gs_vbeln-vbeln.
ENDLOOP.

This approach:

  • Executes one database call per loop iteration

  • Causes performance issues when the number of records increases

In such cases, FOR ALL ENTRIES looks like a reasonable optimization.


Wrong Usage 1: FOR ALL ENTRIES with a Large Internal Table

SELECT *  FROM vbak  INTO TABLE gt_vbak
FOR ALL ENTRIES IN gt_vbeln
WHERE vbeln = gt_vbeln-vbeln.

Problem:

When the internal table gt_vbeln contains a large number of entries:

  • The database generates complex OR conditions

  • Indexes cannot be used efficiently by the database optimizer



Result:

  • Only one SELECT is executed, but it is very expensive

  • Overall performance becomes worse instead of better


Wrong Usage 2: Using FOR ALL ENTRIES without Removing Duplicate Records


FOR ALL ENTRIES transfers the content of the internal table directly to the database. If the internal table contains duplicate keys, This puts unnecessary overhead on the database interface/kernel to handle duplicates.



gt_vbeln = VALUE #(
 ( vbeln = '100001' )
 ( vbeln = '100001' )
 ( vbeln = '100002' ) ).


(SORT gt_vbeln BY vbeln.
DELETE ADJACENT DUPLICATES FROM gt_vbeln COMPARING vbeln.

If this step is skipped, the impact may not be visible for small datasets, but it causes measurable performance degradation in large-volume systems.


Wrong Usage 3: Using FOR ALL ENTRIES Instead of JOIN



One of the most common mistakes is using FOR ALL ENTRIES in scenarios where an INNER JOIN would be the correct and more efficient solution.




SELECT *
  FROM vbak
  INTO TABLE gt_vbak
  FOR ALL ENTRIES IN gt_vbeln
  WHERE vbeln = gt_vbeln-vbeln.

In contrast, a JOIN-based solution:

  • Is better optimized by the database

  • Uses indexes more effectively

  • Requires less memory on the application server

SELECT a~vbeln a~erdat b~posnr
  FROM vbak AS a
  INNER JOIN vbap AS b
    ON b~vbeln = a~vbeln
  INTO TABLE gt_result.

In such scenarios, FOR ALL ENTRIES adds unnecessary overhead and does not provide any performance benefit.


Wrong Usage 4: Missing Check for Empty Internal Table


The most dangerous mistake when using FOR ALL ENTRIES is executing the SELECT statement with an empty internal table.



SELECT *
  FROM vbak
  INTO TABLE gt_vbak
  FOR ALL ENTRIES IN gt_vbeln
  WHERE vbeln = gt_vbeln-vbeln.

If gt_vbeln is empty:

  • The WHERE condition is completely ignored

  • The database reads the entire table

Correct Usage:

IF gt_vbeln IS NOT INITIAL.
  SELECT ...
    FOR ALL ENTRIES IN gt_vbeln
    ...
ENDIF.

This simple check prevents full table scans and serious performance issues in production systems.


Conclusion


FOR ALL ENTRIES is a powerful optimization technique when it is used in the right context. However, when it is applied without understanding its behavior, it can silently turn into a performance problem.

FOR ALL ENTRIES should never be used as a reflex. Instead, developers should always consider:

  • Data volume

  • Duplicate entries

  • JOIN-based alternatives

  • Database behavior and index usage

Used correctly, FOR ALL ENTRIES improves performance. Used incorrectly, it does exactly the opposite.

 
 
 
bottom of page