Exercise 2: Why SELECT ... INTO Can't Find Every Overdrawn Customer, and Why SQLCODE = 100 Is the Right Loop Condition — Possible Solution
====================================================================

WHAT SELECT ... INTO IS GENUINELY LIMITED TO
This chapter's own material states this directly: a plain SELECT ...
INTO can only ever return one real row. It moves exactly one row's
worth of column values into the host variables named after INTO, with
no real mechanism for handling a second, third, or further matching
row at all.

WHY FINDING EVERY OVERDRAWN CUSTOMER GENUINELY NEEDS MORE THAN THAT
The real query in this chapter's own cursor example - WHERE
CUST_BALANCE < 0 - could genuinely match any number of real customer
records, from zero up to the entire table. A single SELECT ... INTO
has no way to receive more than one of those real matching rows; it
would either fail outright or silently return only one of potentially
many genuine matches, which isn't what "find every overdrawn
customer" actually requires.

WHY A CURSOR IS THE GENUINE FIX FOR THIS SPECIFIC PROBLEM
This chapter's own real DECLARE/OPEN/FETCH/CLOSE sequence exists
specifically to traverse a whole real result set one row at a time,
rather than being limited to a single row the way SELECT ... INTO is.
Each real FETCH pulls the next matching row into the host variables,
letting the program genuinely process every overdrawn customer in
turn rather than being stuck with just one.

WHY PERFORM UNTIL SQLCODE = 100 IS GENUINELY THE CORRECT LOOP CONDITION
This chapter's own real compare-table establishes that SQLCODE = 100
specifically means no real row matched - in the context of repeated
FETCH calls against an open cursor, that's the real signal that every
matching row has already been retrieved and there's nothing left to
fetch. Looping until that exact condition is reached means the loop
genuinely continues processing customers for as long as real matching
rows remain, and stops the moment the cursor is genuinely exhausted -
mirroring the same real "keep going until a specific condition fires"
logic Fundamentals' own priming-read pattern used for sequential
files, applied here to a database cursor instead.

ANSWER: SELECT ... INTO can only return a single real row, but the
query for overdrawn customers could genuinely match any number of
real records, so a plain SELECT ... INTO has no way to retrieve them
all - only a cursor, which traverses a whole real result set one row
at a time via FETCH, can process every matching customer in turn.
PERFORM UNTIL SQLCODE = 100 is the correct loop condition because
SQLCODE = 100 is this chapter's own real signal that a FETCH found no
further row - meaning every matching row has already been retrieved -
so looping until that exact code appears correctly continues
processing for as long as real customers remain and stops precisely
when the cursor is genuinely exhausted.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies SELECT ... INTO's real single-row limitation
as the specific reason it can't handle this query, and explains why
SQLCODE = 100 is the genuinely correct termination signal for FETCH
rather than an arbitrary choice.