ABAP SQL Rules That Still Matter on HANA

This is not a single object but a set of coding disciplines around Open SQL access that predate HANA and that many developers assume no longer apply because 'HANA is fast'. The structural fact that explains most of the confusion: HANA removes most of the cost of scanning and aggregating data inside the database engine, but it does nothing about the cost of the round trip between the ABAP application server and the database, and it does nothing about an ABAP program that fetches too much data and then filters, joins or aggregates it in ABAP instead of in SQL. A query that used to be slow because of a missing index can become fast on HANA for the wrong reason, while a query that issues one database call per loop iteration stays exactly as slow, because the bottleneck was never the engine, it was the number of calls.

These rules apply to every piece of custom Open SQL in reports, function modules, class methods and CDS-based logic that touches transactional volume, not just batch jobs. They matter most in loops that read master or transaction data repeatedly, in interfaces that build result sets row by row, and in any code that was migrated from ECC without review. They matter less, though are still good practice, for one-off selection screens against small customizing tables or for code that runs once against a handful of rows. Reaching for a rewrite is a mistake when the object in question is already fast enough for its actual data volume and call frequency; chasing micro-optimizations on a report that runs twice a year against a few hundred rows wastes review time better spent on objects that run in the middle of an order-to-cash flow.

Below this sits the actual HANA database engine and its columnar storage, which rewards selective WHERE clauses and aggregation done inside SQL. Above it sits the ABAP application layer, including internal table processing, CDS views, AMDP procedures and native SQL, all of which are ways of expressing what gets pushed down versus what gets pulled up. These rules do not replace anything on their own; they are the discipline that decides whether code pushdown techniques such as CDS views or AMDP are used correctly or simply relocate a bad pattern from ABAP into SQL. Table buffering, which used to be a primary lever on ECC's disk-based database, is less central on HANA but still relevant for small, frequently read tables where avoiding a round trip beats avoiding a database scan.

A billing report selects header records from VBRK into an internal table, then loops over that table and, for each header, issues a SELECT SINGLE against VBRP to fetch item totals, followed by another SELECT SINGLE against KNA1 for the customer name. On a development system with two hundred billing documents this runs in under a second. On production with two hundred thousand documents it takes twenty minutes and generates hundreds of thousands of individual database calls, each one paying the full round-trip cost regardless of how fast HANA itself is. The fix is not an index or a hint; it is restructuring the access. The header, item and customer data are pulled with a single JOIN or with FOR ALL ENTRIES against a distinct key list, sorted appropriately, with the aggregation for item totals done in the SQL statement rather than in an ABAP loop. The row count returned by the database does not change; the number of round trips drops from three per document to a small constant number for the whole run.

On S/4HANA these rules are enforced more visibly than on ECC because custom code checks run as part of conversion projects flag exactly this class of pattern: SELECT in a loop, missing WHERE conditions, unchecked FOR ALL ENTRIES. Code pushdown through CDS views and AMDP is the sanctioned way to move genuinely set-based logic closer to the data, but under a clean core approach, native SQL and direct table access outside the released API surface are discouraged, and custom logic that needs pushdown should prefer CDS or the extensibility framework rather than hand-written native SQL scattered through custom reports. The rules themselves have not changed; what has changed is that they now surface as concrete findings during a conversion rather than as vague complaints about a slow report.

This is developer territory during coding and code review, with an architect involved only when a decision is made to push logic into CDS or AMDP for a shared, high-traffic object. Handover to functional teams should include realistic production-scale test data, since the whole class of defect described here is invisible against small data sets and only shows up under load.

Read code pushdown from ABAP to HANA before deciding to move a loop's logic into a CDS view or AMDP procedure, since pushdown done on top of a bad access pattern just relocates the problem. ATC checks in an S/4HANA conversion cover the automated detection of many of these patterns and are worth reviewing to understand what gets flagged automatically versus what requires manual review. Custom code migration for S/4HANA is the project context where these rules typically get enforced at scale. Clean core explained for ABAP developers sets the boundary on how far native SQL and AMDP can be used before they conflict with upgrade and extensibility strategy.