Internal Tables Part 1: Standard, Sorted and Hashed Tables

📌 KEY POINTS
✅ An internal table is a temporary, in-memory table in your program — it lives only while the program runs.
✅ It is defined by a line type (structure), a table kind (STANDARD, SORTED, HASHED) and a key.
✅ Classic processing uses a work area: read a row into it, change it, write it back.
⚠️ Never use tables WITH HEADER LINE or OCCURS in new code — they are obsolete and confusing.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

• Part 1 — table kinds and basics (this lesson)
• Part 2 — choosing the right table kind
• Part 3 — work area vs field symbol vs data reference
• Part 4 — READ TABLE and sy-subrc
• Part 5 — SORT, BINARY SEARCH and secondary keys
• Part 6 — APPEND, INSERT, MODIFY, DELETE, COLLECT
• Part 7 — removing duplicates
• Part 8 — LOOP patterns and control levels
• Part 9 — nested loops and parallel cursor
• Part 10 — memory and large tables

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHAT AN INTERNAL TABLE IS
Almost every ABAP program reads data from the database into internal tables, processes it in memory, and outputs or saves the result. Think of it as an array of structures: every row has the same columns (the line type).

━━━━━━━━━━━━━━━━━━━━
▶ 2. THE THREE PARTS OF A DEFINITION

• Line type — usually a dictionary table/structure (SFLIGHT) or a local TYPES structure.
• Table kind — STANDARD, SORTED or HASHED.
• Key — the fields that identify a row (UNIQUE or NON-UNIQUE).

━━━━━━━━━━━━━━━━━━━━
▶ 3. THE THREE TABLE KINDS

• STANDARD TABLE — rows in insertion order, accessed by index or by key with a linear search (slow on large tables unless sorted + BINARY SEARCH). The most common kind in classic code.
• SORTED TABLE — always kept sorted by its key; key access uses a binary search automatically. Key can be UNIQUE or NON-UNIQUE.
• HASHED TABLE — access only by the full unique key via a hash function; constant access time regardless of size; no index access.

━━━━━━━━━━━━━━━━━━━━
▶ 4. CLASSIC DECLARATION WITH A WORK AREA
TYPES: BEGIN OF ty_flight, carrid TYPE s_carr_id, connid TYPE s_conn_id, fldate TYPE s_date, seatsocc TYPE s_seatsocc, END OF ty_flight.
DATA: gt_flights TYPE STANDARD TABLE OF ty_flight,
gs_flight TYPE ty_flight.
The work area gs_flight holds one row at a time.

━━━━━━━━━━━━━━━━━━━━
▶ 5. FILL, READ, LOOP

• Fill from the database: SELECT … INTO TABLE gt_flights.
• Add a row: APPEND gs_flight TO gt_flights.
• Read one row: READ TABLE gt_flights INTO gs_flight WITH KEY connid = '0400'.
• Process all rows: LOOP AT gt_flights INTO gs_flight. … ENDLOOP.
• Count rows: DESCRIBE TABLE gt_flights LINES lv_lines. (💡 Modern: lines( gt_flights ).)

━━━━━━━━━━━━━━━━━━━━
▶ 6. HEADER LINES — WHY NOT
Old code declares DATA itab TYPE … WITH HEADER LINE or OCCURS 0 — the table and a work area with the same name. It is ambiguous (itab vs itab[]) and not allowed in classes. You must read it in legacy code, but never write it.

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

1. Create report ZITAB_BASICS with the code example.
2. Run it for airline LH; see the row count and the loop output.
3. Change the READ key to a connection that does not exist and check sy-subrc = 4.

💡 Modern syntax (7.40+): SELECT … INTO TABLE @DATA(lt_flights), LOOP AT … INTO DATA(ls_flight), lines( ).

✅ CHECKPOINT: you can declare, fill, read and loop over an internal table with a work area.

A support developer changed a legacy report where an internal table was declared WITH HEADER LINE. He wrote CLEAR itab to empty the table, but that only cleared the header line; the table kept old rows and the next run of the loop produced duplicate records in an output file.
The team fixed it with CLEAR itab[] and, in the next change, replaced the header line with an explicit work area. They added "no header lines in new code" to their review checklist.

• Declaring new tables WITH HEADER LINE or OCCURS.
• Confusing itab and itab[] in legacy code.
• Not checking sy-subrc after READ TABLE.
• Forgetting CLEAR on the work area before filling a new row.
• Using a standard table for large key lookups without sorting.

• Use explicit work areas (or field symbols) and no header lines.
• Base line types on dictionary structures or clear local TYPES.
• Choose the table kind based on access pattern (Part 2).
• Always check sy-subrc after READ.
• Keep tables local to the processing that needs them.

Questions: "What is an internal table?", "Difference between standard, sorted and hashed tables?", "Why avoid header lines?"
Strong answer: an internal table is an in-memory table defined by line type, table kind and key; standard tables keep insertion order with index access and linear key search, sorted tables keep key order with automatic binary search, hashed tables allow only unique-key access with constant time; header lines are obsolete, ambiguous (itab vs itab[]) and not allowed in OO contexts.