Wow -- talk about convoluted. I just figured out why it was only happening for QA's records. I had checked buffering before for the cursor and insured that it was indeed 1. When I tried on their records today, it was 3, which threw me for a loop. Then I discovered that their records were from an SQL data source, not native -- that was the difference.
Here is what was happening:
In a working condition (my testbed) the system was selecting from a local VFP table using SELECT * FROM Table WHERE Unum = "XXXXXXXXXX" -- this cursor reported a setting of "1" for buffering using CURSORGETPROP.
In a non-working condition (some of the QA records) the system was selecting from a remote SQL table using the same query. The returned cursor had a setting of "3" for buffering using CURSORGETPROP. I, of course, simply tried to change it to 1 -- VFP would not allow that saying that a setting of 1 was invalid on a "remote view". This cursor was obtained using SQLEXEC.
So the solution is as follows:
IF CURSORGETPROP("Buffering", Table) # 1
SELECT * FROM Table INTO CURSOR Table
=CURSORSETPROP("Buffering", 1, Table)
ENDIF
Now all records on my testbed are working.
Re-submitting to QA...