Debugging Part 5: Debugging Internal Tables and Field Symbols

📌 KEY POINTS
✅ The debugger's table tool shows content, lets you filter/sort columns and compare tables (Diff tool) — faster than scrolling.
✅ Classic bugs: BINARY SEARCH on an unsorted table, READ TABLE without checking sy-subrc, work area not cleared, wrong table key.
✅ Field symbols: GETWA_NOT_ASSIGNED dumps if used before assignment; a field symbol assigned to a row changes that row directly.
⚠️ After READ TABLE fails, the work area still holds the previous row — using it without sy-subrc check gives silently wrong results.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 4 found value changes. Internal tables are where many ABAP bugs hide.

━━━━━━━━━━━━━━━━━━━━
▶ 1. TABLE TOOL

• Double-click a table in the variables view → table tool.
• Filter/sort columns, search values, show line count (LINES).
• Change/insert/delete rows (test systems only).
• Diff tool: compare two tables (e.g. before/after a routine).

━━━━━━━━━━━━━━━━━━━━
▶ 2. READ TABLE PROBLEMS

• BINARY SEARCH requires the table sorted by exactly the search key fields; otherwise random misses.
• READ TABLE … FROM wa uses the default key (for standard tables: all character-like fields) — use WITH KEY for clarity.
• Always check sy-subrc; CLEAR the work area before reading if the result is used anyway.

━━━━━━━━━━━━━━━━━━━━
▶ 3. WORK AREAS AND HEADER LINES

• Tables with header lines (old code): "itab" can mean the header or the body — confusing in debugging; the debugger shows both (itab[] vs itab).
• Work areas not cleared between loop passes carry values into the next row.

━━━━━━━━━━━━━━━━━━━━
▶ 4. FIELD SYMBOLS

• Check "assigned" status in the debugger; IS ASSIGNED in code.
• LOOP … ASSIGNING <fs>: changes to <fs> change the table row directly (no MODIFY needed).
• After the loop, <fs> still points to the last row — changing it later modifies that row unexpectedly.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DUPLICATES AND SORTING

• Duplicate keys after APPEND in loops → use SORT + DELETE ADJACENT DUPLICATES or sorted/hashed tables with unique keys.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Run the code example in the debugger and inspect the table after SORT.
2. Remove the SORT and watch BINARY SEARCH miss.
3. Check the field symbol's assignment after the loop.

✅ CHECKPOINT: you can diagnose internal table and field symbol bugs quickly.

A stock report showed correct numbers for most materials but zero for some. The table was sorted by MATNR only, while READ TABLE used BINARY SEARCH with MATNR and WERKS. For materials in several plants, the binary search randomly missed, and the code used the previous work area value because sy-subrc was not checked.
Sorting by both key fields and checking sy-subrc fixed it. The team later switched the lookup table to a sorted table with a unique key.

• BINARY SEARCH on differently sorted tables.
• No sy-subrc check after READ TABLE.
• Work areas not cleared.
• Using field symbols after the loop.
• Duplicate rows from repeated APPENDs.

• Use the table tool with filters and Diff.
• Sort by exactly the search key or use sorted/hashed tables.
• Check sy-subrc every time.
• UNASSIGN field symbols after use.
• Prefer explicit WITH KEY / WITH TABLE KEY.

Questions: "Why does READ TABLE BINARY SEARCH sometimes fail?", "What happens to a field symbol after LOOP ASSIGNING?", "How do you inspect tables in the debugger?"
Strong answer: binary search requires sorting by the exact key; check sy-subrc and clear work areas; ASSIGNING changes rows directly and stays assigned to the last row after the loop (UNASSIGN); table tool with filter/sort/Diff; default key pitfalls; duplicates.