>>>SNIP
>>>>>When a new memo is added or an existing is changed the blocks are allocated in 64 byte chuncks, so on average there is a waste of 32 bytes/memo
>>>>>Changing a memo does not happen 'in place', the whole memo is rewritten, the old apace is not re-used, hence the bloat
>>>>
>>>>This is not true, if LEN(memo) it doesn't overcome CEILING(LEN(memo)/BLOCKSIZE)*BLOCKSIZE
>>>>blocksize it rewritten the memo in place.
>>>>
>>>SNIP
>>>
>>>Fabio,
>>>
>>>Please check out Re: .FPT files - bloat and re-writing of file header Thread #971406 Message #972068
>>>
>>>It says, as I read it, that memo field is always re-written.
>>>
>>>cheers
>>
>>hi Jim,
>>
>>Funny. I had done a few tests after Fabio's reply and my tests indicated Fabio was right (he usually is). I created a free table and did 100,000 replaces.
>>But then, I had the table exclusively and not buffered
>>
>>Thanks for digging this one up. I must have read that message before. Just could not remember it
>
>I think just shared is enough to do the trick.
>
>cheers

Not!!!! The VFP implementation is too simple.

With a cursor (exclusive) and a buffer 3 every replace realloc another memo block
( 1 is sufficient ).
The following builds a temporary file of 510MB ( expected 20MB )

CREATE CURSOR mycursor (mbloat m)
REPLACE mbloat WITH SPACE(10000000)
CURSORSETPROP("Buffering",3)
FOR K=1 TO 50
	REPLACE mbloat WITH SPACE(10000000)
NEXT
USE

the question is:
if I use the 5 levels of BEGIN TRAN above a buffered transactable cursor,
what happens in the memo?
It is better perhaps that I don't look.