John,

You have a mistaken assumption. Whenever the memo size increases VFP is going to reallocate a new block of fpt to hold the content. This behavior goes back to VFP6 which is the oldest version I still have installed.

set blocksize to 32
create table employee ( id i, notes m )
insert into employee values ( 1, replicate( "x", 2000016 ) )
use in employee

create cursor sizes ( iMemosize i, iFPTSize i )

FOR ix = 1 TO 100
   use employee exclusive in 0
   lnSize = max( 1, int( rand() * 2000000 ) )
   replace notes WITH REPLICATE('a', lnSize ) in Employee
   use in employee
   adir( laFile, "employee.fpt" )
   insert into sizes values ( lnSize, laFile[2] )
ENDFOR

select sizes
brow last nowait

As long as the memo size is the same or smaller it is put back into the same place. Whenever it increases in size the old allocation is trashed and it is completely reallocated to new space at the end of the fpt. It does this so that it doesn't have waste time to check the block allocation of every record and memo.

This wouldn't be necessary if VFP stored 3 integers in the memo header: deleted, current size, allocated space. Heck it'd be nice if VFP would reuse deleted memo space too, but that isn't in the cards either.

set blocksize to 64
set exclusive on

* creates two memos the first needs 2 64 byte blocks and the second only needs 1

create table bloat ( id i, notes m )
insert into bloat values ( 1, replicate( "x", 100 ) )
insert into bloat values ( 2, "second memo" )
use in bloat

hexedit( "bloat.fpt" )

* update the first memo, size is still under 64 * 2 - 8, so the a's write over the x's

use bloat
replace notes with replicate( "a", 110 )
use

hexedit( "bloat.fpt" )

* this memo now exceeds the two blocks it has allocated, so it requires 3 blocks at the end of the file.

use bloat
replace notes with replicate( "b", 140 )
use

hexedit( "bloat.fpt" )

* again the size is under 3 blocks so the c overwrites the first b

use bloat
replace notes with replicate( "c", 1 )
use

hexedit( "bloat.fpt" )

run the above code through each hexedit() call at a time and examine what goes on inside the fpt.

Despite all your other "I can't possibly change this code" statements, you seriously need to rethink your algorithm and change it to something that doesn't rely on memo fields if you are constructing a memo that is always increasing in size.

>I have always relied on the fact that memo bloat does not exist in any cursor or table that is opened exclusively. This issue has made me confirm that many, many times now. I've created a table (and also a cursor) with a single memo field in it. I have then made a tight loop, replacing the contents hundreds of thousands of times with no problem. So either the memo bloat can occur if "foxpro is really busy" (which I find really hard to believe) or there is something else at work here...