What is the "SELECT * usage" issue in S/4HANA migration?

SELECT * reads all columns including new S/4HANA columns, causing unexpected results and performance issues. S/4HANA adds columns to core tables. SELECT * returns new columns that legacy code cannot handle.

How much effort does it take to fix "SELECT * usage"?

Remediation effort is rated S — Small (hours). Severity: HIGH.

Which tool checks for SELECT * usage automatically?

The s4ready.ai A1 Readiness Scanner checks for SELECT * usage (and 29 other rules) automatically across your custom ABAP codebase. Results include object-level findings with severity and effort estimates.

HIGH Effort: S — Small (hours) ABAP SQL

How to remediate: SELECT * usage

SELECT * reads all columns including new S/4HANA columns, causing unexpected results and performance issues.

Is this issue in your codebase?

A1 scans all 30 rules across your custom ABAP — results in minutes.

Scan your codebase free →

What changes in S/4HANA

S/4HANA adds columns to core tables. SELECT * returns new columns that legacy code cannot handle.

Before and after: ABAP code example

Before (ECC)

* ECC: reads ALL columns — breaks with new S/4HANA columns
SELECT * FROM mara
  INTO TABLE @DATA(lt_mara)
  WHERE matnr IN s_matnr.

After (S/4HANA)

* S/4HANA: explicit field list — stable and performant
SELECT matnr, mtart, mbrsh, meins, maktx
  FROM i_material
  INTO TABLE @DATA(lt_material)
  WHERE material IN @s_matnr.

Effort estimate and common pitfalls

Effort estimate

S — Small (hours)

Estimate is per affected object. Total effort scales with the number of occurrences in your codebase. Use the A1 scan to get an object-level count before estimating the full project.

Common pitfalls

! Forgetting to update all occurrences in the same program
! Not running ATC after the change to confirm the finding is resolved

Related rules to check

HIGH S

Missing FOR ALL ENTRIES guard

FOR ALL ENTRIES IN without an initial-table check returns the full table when the driver table is empty.

CRITICAL L

Native SQL (EXEC SQL)

EXEC SQL and ADBC bypass ABAP SQL layer and break on S/4HANA HANA database.

CRITICAL XL

Direct pool/cluster table access

Direct reads from BSEG, KONV, STXL and other pool/cluster tables. These tables are dissolved in S/4HANA.

Find every instance of this issue in your codebase

The A1 scanner checks all 30 compatibility rules — including SELECT * usage — across your custom ABAP objects and produces a prioritised remediation backlog.

Scan your codebase for this issue free →

← All remediation rules Resources →

SAP, S/4HANA and ABAP are trademarks of SAP SE. s4ready.ai is an independent solution and is not affiliated with, endorsed by, or sponsored by SAP SE.