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)  && PROBABLY NOT NECESSARY, AS ONLY SQL CURSORS ARE BEING DEFAULTED TO 3 IN THIS MODULE
ENDIF

Now all records on my testbed are working.

Re-submitting to QA...