Introduction
Many UK companies have already migrated to SAP S/4HANA, expecting immediate performance improvements.
However, in practice, many systems feel slower than before.
The reason is often not SAP HANA itself — but legacy ABAP Open SQL code that was never designed for a column-based, in-memory database.
This article explains practical ABAP Open SQL best practices for S/4HANA, focusing on performance, stability, and long-term cost efficiency for UK SAP teams.
Why Open SQL Matters in S/4HANA
SAP HANA is fundamentally different from traditional databases used in ECC systems.
Key differences:
- Column-based storage instead of row-based
- In-memory processing
- Optimised for set-based operations, not loops
If ABAP Open SQL is written with an ECC mindset, HANA cannot deliver its full potential — and infrastructure costs increase unnecessarily.
For UK companies running SAP in cloud environments, inefficient Open SQL directly translates to higher operating costs.
Core ABAP Open SQL Best Practices for S/4HANA
Avoid SELECT * at All Costs
Using SELECT * fetches unnecessary columns, increasing:
- Network load
- Memory consumption
- CPU usage
Best practice:
Always select only the fields you actually need.
SELECT vbeln, erdat, netwr
FROM vbak
INTO TABLE @DATA(lt_vbak)
WHERE erdat >= @lv_date.
This allows SAP HANA to optimise column access efficiently.
Use Proper WHERE Conditions (Early Filtering)
A missing or weak WHERE clause often causes full table scans — one of the most common performance killers.
Best practice:
- Filter as early as possible
- Avoid filtering in ABAP loops
- Push logic down to the database
Bad pattern:
SELECT vbeln, erdat
FROM vbak
INTO TABLE @DATA(lt_vbak).
DELETE lt_vbak WHERE erdat < lv_date.
Correct approach:
SELECT vbeln, erdat
FROM vbak
INTO TABLE @DATA(lt_vbak)
WHERE erdat >= @lv_date.
Prefer JOINs Over FOR ALL ENTRIES
FOR ALL ENTRIES is still widely used in legacy UK systems, but it often produces unpredictable execution plans in S/4HANA.
Best practice:
Use database joins whenever possible.
SELECT a~vbeln, b~posnr, b~matnr
FROM vbak AS a
INNER JOIN vbap AS b
ON a~vbeln = b~vbeln
INTO TABLE @DATA(lt_result)
WHERE a~erdat >= @lv_date.
Joins are optimised by HANA and scale far better for large datasets.
Use Modern ABAP Syntax
Modern ABAP improves:
- Readability
- Maintainability
- Onboarding speed for new developers
Examples:
- Inline declarations
- Host variables (
@) - Expressions
Cleaner code reduces long-term support costs — a key concern for UK SAP teams.
Be Careful with SELECT SINGLE
SELECT SINGLE does not guarantee deterministic results unless the full primary key is used.
Best practice:
- Use
SELECT SINGLEonly with full keys - Otherwise, use
UP TO 1 ROWSwith explicit ordering
This avoids subtle production bugs that are difficult to trace.
Real-World Example from a UK SAP Landscape
A UK-based logistics company migrated to S/4HANA but experienced a 30% increase in response times.
Root cause:
- Multiple
SELECT * - Heavy use of
FOR ALL ENTRIES - Filtering done in ABAP instead of SQL
After refactoring Open SQL:
- Average response time improved by 40%
- Database load decreased significantly
- Cloud infrastructure costs were reduced
The HANA database was never the problem — the ABAP design was.
Common Mistakes UK SAP Teams Still Make
- Assuming “it worked in ECC, so it’s fine”
- Overusing CDS views without understanding execution costs
- Ignoring SQL trace and performance analysis
- Treating ABAP and database design as separate concerns
In S/4HANA, ABAP and database performance are inseparable.
Final Takeaway
SAP S/4HANA rewards clean, efficient Open SQL design.
Poor Open SQL:
- Increases infrastructure costs
- Slows down business processes
- Creates unnecessary operational risk
Optimised Open SQL:
- Improves performance
- Reduces cloud spend
- Future-proofs your SAP landscape
If your S/4HANA system feels slower than expected, the problem is often not HANA — it’s the ABAP.