Open SQL in ABAP: How Data Is Really Fetched from SAP Tables

When I first started writing ABAP programs, SELECT felt simple.

Just write:

SELECT * FROM mara INTO TABLE it_mara.

And boom — data appears.

But over time, I realized something important.

Open SQL is not just about fetching data.
It’s about how responsibly you fetch it.

And in SAP systems — responsibility matters.

What Open SQL Really Is

Open SQL is SAP’s database-independent way of communicating with the database.

When I write a SELECT statement in ABAP, I’m not directly talking to SAP HANA or Oracle. I’m talking to the ABAP layer, which then translates my query into something the database understands.

That abstraction is powerful.

It means:

My code works across different databases
Authorization checks are handled
SAP buffering is respected
I stay aligned with SAP standards

And honestly, that’s one reason SAP systems are so stable.

What Actually Happens When I Write SELECT

Let’s say I write:

SELECT matnr, mtart
  FROM mara
  INTO TABLE @DATA(it_materials)
  WHERE mtart = 'FERT'.

Behind the scenes, this is what happens:

ABAP validates the table structure via DDIC
It checks authorizations
It converts Open SQL into database-specific SQL
The database executes it
Results are sent back to the application server
Data is stored in an internal table

All this in milliseconds — if written properly.

That “if” is important.

The Mistake I Used to Make

In the beginning, I used SELECT *.

It’s convenient.

But now I understand why it’s risky.

When I use:

SELECT * FROM mara INTO TABLE @DATA(it_mara).

I’m pulling every column — even if I only need two.

That means:

More memory usage
More network transfer
Slower performance on big tables

Now I always try to fetch only what I need:

SELECT matnr mtart
  FROM mara
  INTO TABLE @DATA(it_mara).

It’s a small habit.
But small habits define clean developers.

SELECT Inside LOOP – The Silent Performance Killer

I’ve seen this pattern:

SELECT * FROM vbak INTO TABLE @DATA(it_vbak).

LOOP AT it_vbak INTO DATA(ls_vbak).
  SELECT * FROM vbap
    WHERE vbeln = @ls_vbak-vbeln.
ENDLOOP.

It works.

But it’s dangerous.

Because now the program hits the database again and again — once per loop iteration.

Instead, I now prefer joins:

SELECT a~vbeln, b~posnr
  FROM vbak AS a
  INNER JOIN vbap AS b
    ON a~vbeln = b~vbeln
  INTO TABLE @DATA(it_sales).

One database trip is better than hundreds.

SAP systems scale because developers think this way.

Open SQL and HANA Changed My Thinking

With SAP HANA, the mindset shifted.

Earlier, it was common to:

Fetch large datasets
Process everything in ABAP
Aggregate manually

Now, I try to push logic down to the database:

Use GROUP BY
Use SUM and COUNT
Use CASE
Use CDS Views when needed

The database engine is optimized for heavy computation.

If I ignore that, I’m wasting system capability.

Buffering – Something I Underestimated

Some tables are buffered.

Which means:

The system might not even hit the database
Data could be served directly from memory

But buffering is not magic.

It doesn’t apply to everything.
And it shouldn’t be blindly trusted.

Understanding when data is buffered is part of writing intelligent Open SQL.

What I’ve Learned About Open SQL

Open SQL is not about syntax.

It’s about:

Writing scalable queries
Respecting indexes
Reducing unnecessary data transfer
Thinking in sets, not loops
Letting the database do its job

Anyone can write a SELECT statement.

But writing one that scales in production — that’s a skill.

Final Thought

The more I work with ABAP, the more I realize something:

Good Open SQL doesn’t just fetch data.
It protects performance.
It respects architecture.
It keeps systems stable.

And in enterprise software, stability is everything.

Command Palette