ABAP JOIN vs FOR ALL ENTRIES
A database JOIN combines related tables in one SQL statement, while FOR ALL ENTRIES (FAE) builds a database selection from values already held in an ABAP internal table. Prefer a JOIN when the relationship exists entirely in the database and can be expressed cleanly. Use FAE when the driving keys genuinely originate in ABAP memory or when a join is impractical, and always guard against an empty driver table.
Practitioner guide to ABAP JOIN vs FOR ALL ENTRIES: what it means, when to use it, how it fits SAP architecture, a concrete support/development example, decision rules, production pitfalls, S/4HANA implications, ownership, and related technical objects.
Reviewed by an ERPClimb SAP consultant on 20 Sept 2026· 719 words
What it is
JOIN and FOR ALL ENTRIES solve different data-access shapes. A JOIN lets the database optimizer combine tables and apply filters before rows cross to the ABAP server. FAE takes a driver internal table and creates a logical disjunction of matching conditions for the selected database table; the database interface may split the request into several statements depending on size and platform parameters. Crucially, if the FAE driver is empty, the FAE condition is ignored and the remaining WHERE condition can select a much larger result set. That empty-driver rule is why an IS NOT INITIAL guard is mandatory.
When to use it
Use an inner/outer JOIN when all source data is relationally available in the database and the result can be produced with clear join conditions. Use FAE when keys were calculated in ABAP, came from a file/API, or must drive a second database read after application logic. For very large driver sets, consider whether a join, CDS view, temporary persistence, ranges, or another set-oriented design is better. The right answer is not 'FAE is faster' or 'JOIN is always faster'; data shape and optimizer plan decide.
How it fits the stack
This decision belongs to Open SQL performance design. It interacts with CDS views, associations, database indexes, result-set size, and HANA pushdown. On HANA, set-oriented database operations are usually preferable to pulling data up and re-querying row by row. FAE remains valid ABAP, especially when the driver does not exist as a database relation. ST05 and SQL Monitor are better evidence than folklore because they show how many SQL statements ran and how many rows were transferred.
A worked example
A report needs MARA attributes for all materials appearing in MSEG. If the material list comes directly from a database query, a JOIN can often retrieve the required data in one optimized statement. If the material list instead comes from an uploaded spreadsheet and has been validated in ABAP, FAE may be appropriate. Before the FAE SELECT, the program removes duplicates and checks that the driver table is not initial. ST05 then verifies the actual SQL and transferred rows on realistic data.
How to choose
- If both datasets already exist in the database, try a JOIN or CDS model first.
- If the driver values originate outside the database or after ABAP-only logic, FAE can be natural.
- Always check the FAE driver table for NOT INITIAL before executing the SELECT.
- Select only required columns and push filters to the database in either approach.
- Use ST05/SQLM on realistic volume when the choice is performance-sensitive.
Common pitfalls
- Running FAE with an empty driver table and unexpectedly reading nearly the entire source table.
- Using SELECT * and then debating JOIN versus FAE while transferring far more columns than needed.
- Creating a driver table with huge duplicate key sets and assuming the database interface will optimize them away cheaply.
- Replacing a simple join with multiple staged selects because older project folklore says joins are slow.
- Ignoring outer-join/null semantics when converting between JOIN and staged reads.
ECC, S/4HANA and clean core
Both JOIN and FOR ALL ENTRIES remain supported in S/4HANA. HANA's optimizer and column-store execution make set-oriented database processing especially effective, but the application still needs good predicates and manageable result sets. Clean-core rules may influence which tables/CDS entities you may read directly, so a released CDS view can be the correct join source even when classic code once joined transparent tables.
Whose problem this is
ABAP developers own the SQL design and empty-driver protection. Performance specialists validate with trace data. Functional owners provide the business join cardinality and completeness rules—for example, whether missing child records should remove a row or require outer-join behavior.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-technical-topics/abap-join-versus-for-all-entriesERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.