This problem crept us on us due to a very subtle code change from one version of our product to the next. Both versions were running VFP 9. And yes, you were correct in saying that the first value is the largest that it can ever be.

In the previous version of our product, the record pointer was on a specific place in a VFP table. When "nesting" to work with sub-sets of the memo field, a SELECT statement with a subsequent REPLACE of the data in the memo field was done before the recursive call and then that query was simply closed when the recursive call was complete. I should also mention that the alias of the table was renamed prior to the recursive call to something unique, the SELECT went into an alias of the same name that the "parent" table used to be, and upon completion of the recursive program call, the temporary cursor was closed and the original table alias was changed back to what it was prior to the recursive call. No REPLACES, no memo bloat. (I must say, though, that many parts of the program rely on cursors not experiencing memo bloat -- we have never been bitten by it, but rest assured we will be examining each and every case in the near future.)

The new version of our product starts the entire process with a single record in that cursor. The reasons for this are complex, but work entirely in our favor. We no longer have to assure that we are always on the correct record -- there is only one. That record can come from VFP or any other SQL data source, etc. While we could go back (with some effort) to the old logic, many users have enjoyed the new speed of the replace. There are no more recursive SELECT statements that cause temporary files and the performance is a ton faster. I have the skeleton of a "smart" refresh that will, upon necessity, re-select the data into itself and eliminate the memo bloat -- it's just not a great way to solve the problem.

Remind me to ask the VFP team for a SET MEMOBLOAT OFF command in the next version!!! :D