Common Pitfalls & Defect Patterns

• QuestionWhat is "Open SQL pitfalls"?Tap to revealAnswerFOR ALL ENTRIES on an empty table returns EVERYTHING, and SELECT SINGLE without the full key returns a random row — guard the driver and qualify the key.
• QuestionIn "Open SQL pitfalls", explain:Tap to revealAnswerSELECT SINGLE without the full key returns an undefined row — fully qualify the key or add ORDER BY.
• QuestionIn "Open SQL pitfalls", explain:Tap to revealAnswerFOR ALL ENTRIES on an empty driver returns ALL rows — always guard with `if lines( itab ) > 0`.
• QuestionIn "Open SQL pitfalls", explain:Tap to revealAnswerFOR ALL ENTRIES silently de-duplicates the driver; it can never deliver 1:1 cardinality — use a JOIN.
• QuestionIn "Open SQL pitfalls", explain:Tap to revealAnswerINTO CORRESPONDING is slow and hides type mismatches; ORDER BY PRIMARY KEY and DISTINCT are not free.
• QuestionAnalogy for "Open SQL pitfalls":Tap to revealAnswerAn empty 'only these IDs' filter isn't 'show nothing' — it's 'show everything', like an empty search box returning the whole catalog.
• QuestionWhat is "Internal-table pitfalls"?Tap to revealAnswerBINARY SEARCH on an unsorted table silently returns garbage with no dump — and a field symbol already edits the row, so MODIFY ... INDEX is redundant.
• QuestionIn "Internal-table pitfalls", explain:Tap to revealAnswerBINARY SEARCH on an unsorted table = undefined result, NO dump — only use it on ascending-sorted data.
• QuestionIn "Internal-table pitfalls", explain:Tap to revealAnswerLOOP ... INTO copies the row; LOOP ... ASSIGNING <fs> binds it in place (faster, mutable).
• QuestionIn "Internal-table pitfalls", explain:Tap to revealAnswerMODIFY ... INDEX inside a field-symbol loop is redundant — assigning to <fs> already mutated the row.
• QuestionIn "Internal-table pitfalls", explain:Tap to revealAnswerSORT is unstable unless you add STABLE; HASHED inserts benefit from INITIAL SIZE; DELETE ... WHERE is O(n).
• QuestionAnalogy for "Internal-table pitfalls":Tap to revealAnswerBinary search on an unsorted list is like looking up a word in a dictionary whose pages were shuffled — you confidently land on the wrong page.
• QuestionWhat is "RAP pitfalls"?Tap to revealAnswerAn ETag pinned to a field that never changes silently switches off optimistic locking — anchor it to a LocalLastChangedAt that a determination bumps.
• QuestionIn "RAP pitfalls", explain:Tap to revealAnswerAn ETag on a non-changing field silently disables optimistic locking — use a LocalLastChangedAt updated by a determination.
• QuestionIn "RAP pitfalls", explain:Tap to revealAnswerREAD/MODIFY ENTITIES IN LOCAL MODE skips DCL — fine inside the BO, a leak if surfaced without re-checking auth.
• QuestionIn "RAP pitfalls", explain:Tap to revealAnswerUPDATE FIELDS ( ... ) is an allow-list — a field you forget to list is silently not updated, no error.
• QuestionIn "RAP pitfalls", explain:Tap to revealAnswerLate numbering (ADJUST_NUMBERS) runs after determinations — you cannot read the assigned key before it.
• QuestionAnalogy for "RAP pitfalls":Tap to revealAnswerA version stamp that never increments is like a tamper seal that is already broken — it can never tell you the box was opened.
• QuestionWhat is "CDS pitfalls"?Tap to revealAnswerCDS cardinality is a hint to the optimizer, not a rule it enforces — and #CHECK with no DCL activates fine but dies at runtime.
• QuestionIn "CDS pitfalls", explain:Tap to revealAnswerCardinality [1..1] is a declaration to the optimizer, NOT an enforced constraint — wrong cardinality corrupts joins silently.
• QuestionIn "CDS pitfalls", explain:Tap to revealAnswer@AccessControl.authorizationCheck: #CHECK without a matching DCL activates fine, then fails at runtime on first access.
• QuestionIn "CDS pitfalls", explain:Tap to revealAnswer@Consumption.* annotations only take effect in projection/consumption views; on interface views they are ignored.
• QuestionIn "CDS pitfalls", explain:Tap to revealAnswerPath-expression pushdown depends on cardinality — verify with EXPLAIN rather than assuming.
• QuestionAnalogy for "CDS pitfalls":Tap to revealAnswerDeclaring [1..1] is like labelling a box 'contains one item' — the label changes nobody's behaviour if you actually stuffed three inside.
• QuestionWhat is "AMDP & ABAP Cloud pitfalls"?Tap to revealAnswerAn AMDP whose USING omits a referenced table activates fine but dumps at first run, and missing OPTIONS READ-ONLY costs you reader-node routing.
• QuestionIn "AMDP & ABAP Cloud pitfalls", explain:Tap to revealAnswerUSING must list ALL referenced DB objects — a missing entry activates fine but fails at first execution.
• QuestionIn "AMDP & ABAP Cloud pitfalls", explain:Tap to revealAnswerAMDP parameters are SQLScript types, not ABAP types — implicit conversions can lose precision.
• QuestionIn "AMDP & ABAP Cloud pitfalls", explain:Tap to revealAnswerForgetting OPTIONS READ-ONLY on a read-only AMDP forfeits reader-node routing in scale-out.
• QuestionIn "AMDP & ABAP Cloud pitfalls", explain:Tap to revealAnswerABAP_CLOUD_DEVELOPMENT_DEFAULT gains checks each release (green today, red after an FPS); IF_T100_MESSAGE is the released text approach.
• QuestionAnalogy for "AMDP & ABAP Cloud pitfalls":Tap to revealAnswerUSING is the packing list for a shipment — if a parcel isn't on the list, customs (the runtime) stops the whole truck on arrival.
• QuestionWhat is "Transport & topology pitfalls"?Tap to revealAnswerCoupled objects — view+DCL, BDEF+pool, binding+draft tables — must travel in the same transport, or the target system is left half-wired.
• QuestionIn "Transport & topology pitfalls", explain:Tap to revealAnswerA CDS view's DCL role is a separate object — it isn't auto-transported unless it's in the same transport as the view.
• QuestionIn "Transport & topology pitfalls", explain:Tap to revealAnswerA behavior-pool change without its BDEF produces 'outdated' warnings on the target — move the pair together.
• QuestionIn "Transport & topology pitfalls", explain:Tap to revealAnswerOData V4 service bindings carry a draft node — exporting without the draft tables leaves a half-working service.
• QuestionIn "Transport & topology pitfalls", explain:Tap to revealAnswerThe common shape: a model split across objects; transport all of it or the target is half-wired.
• QuestionAnalogy for "Transport & topology pitfalls":Tap to revealAnswerShipping a lock without its key: the door arrives installed, but nobody on the other end can actually open it.

1. 1Outline the core idea

   Analyse~10 min

   In your own words, outline the central idea of "Open SQL pitfalls". Aim for one paragraph, no jargon you haven't earned.

   Done when: A non-expert could read your paragraph and explain it back to you.

   Re-read the source concept

2. 2Solve it to a real situation

   Apply~15 min

   Find a real situation from your own work / life where "Transport & topology pitfalls" applies. Solve the idea — describe the situation, the move you'd make, and the alternative you considered first.

   Done when: You can name a specific situation (not a hypothetical), state your move, and explain the trade-off in one paragraph.

   Re-read the source concept

3. 3Teach it back

   Evaluate~5 min

   Pick someone (a colleague, a peer, a rubber duck) and explain the section to them in under 5 minutes. Use your own example, not the one from the lesson.

   Done when: Your listener can repeat the core idea + the trade-off back to you without prompting.

Why this matters. Reading + quizzing prove recall; applying it in a real situation is the only evidence of transfer. Treat at least one of these as non-negotiable before you move on.