Hi,
This is why I suggested scanning the file and find the max memo data size then add 20% to it then insert dummy data equal to this size, then the fpt won't bloat, just write to the same set of blocks.

>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...