Less-obvious pitfalls
What you'll learn
These less-obvious pitfalls corrupt results silently: BINARY SEARCH and DELETE ADJACENT DUPLICATES both assume a prior SORT, and UP TO 1 ROWS needs an explicit ORDER BY.
- PACKAGE SIZE issues separate DB calls and can break consistent-read; use cursoring deliberately.
- MODIFY into a HASHED table reallocates buckets — prefer INSERT INTO a SORTED table on hot paths.
- DELETE ADJACENT DUPLICATES needs a prior SORT by the same fields, or it misses non-adjacent dups.
These are the quieter traps that produce wrong results without a dump. SELECT ... INTO TABLE ... PACKAGE SIZE n issues separate database calls and can break consistent-read in some isolation modes, so reach for explicit cursoring only when you truly need it. MODIFY ... FROM TABLE into a HASHED target reallocates buckets and is costly on hot paths — prefer INSERT INTO TABLE with a SORTED table when you are building up data in a loop.
Two ordering assumptions cause silent corruption. DELETE ADJACENT DUPLICATES only removes duplicates that are physically adjacent, so without a prior SORT by the same comparison fields you delete some but not all duplicates. READ TABLE ... BINARY SEARCH assumes the table is already sorted ascending by the search key in declaration order; on an unsorted standard table the result is undefined — and there is no runtime error to warn you.
The rest reward precision: COLLECT requires numeric addend components and a unique non-addend key, or it silently mis-totals; LOOP AT ... GROUP BY is HANA-friendly because it streams; and SELECT ... UP TO 1 ROWS needs an explicit ORDER BY (typically ORDER BY PRIMARY KEY) for 'the first row' to mean anything deterministic.
Key points
- PACKAGE SIZE issues separate DB calls and can break consistent-read; use cursoring deliberately.
- MODIFY into a HASHED table reallocates buckets — prefer INSERT INTO a SORTED table on hot paths.
- DELETE ADJACENT DUPLICATES needs a prior SORT by the same fields, or it misses non-adjacent dups.
- READ TABLE BINARY SEARCH on an unsorted table is undefined — no dump, just wrong results.
- SELECT UP TO 1 ROWS needs an explicit ORDER BY to be deterministic.
Examples
On an unsorted table only physically adjacent duplicates vanish — scattered duplicates survive.
ABAPdelete adjacent duplicates from lt_items
comparing matnr werks.Sorting by the same fields first makes every duplicate adjacent, so all of them are removed.
ABAPsort lt_items by matnr werks.
delete adjacent duplicates from lt_items
comparing matnr werks.Undefined result and no runtime error — the read may report not-found for a row that exists.
ABAPread table lt_items into data(ls_item)
with key matnr = '4711'
binary search.Either sort by the search key first, or declare a SORTED table so the read is well-defined.
ABAPsort lt_items by matnr.
read table lt_items into data(ls_item)
with key matnr = '4711'
binary search.Pitfalls
- Calling DELETE ADJACENT DUPLICATES or READ ... BINARY SEARCH without first SORTing by exactly those fields.
- Assuming LOOP AT a HASHED table iterates in a meaningful order — hash order is undefined.
Source notes: clean-core-curriculum §2.3
Ask Claude
Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.