This is from the Hacker's Guide to VFP6. Hope it helps:
Each time data is written to a memo field, new blocks are added to the end of the FPT, data is added to them, and then the pointer contained within the memo header is updated to point at the new data. The old data remains within the file, and the space it occupied is not reclaimed. Over a period of time, memo fields can grow beyond control without containing that much information. This is the dreaded "memo field bloat." The relatively new ADDITIVE clause of the REPLACE command does not alleviate this, it just makes it easier to tack one more sentence onto the end of a long memo—internally, the same process occurs.

In development, you can reclaim the space with the command PACK MEMO. This packs the file in place, replacing the memo field with a far more compact one. However, as we discuss in "Commands to Use Only Interactively," the PACK command leaves the developer in the dark if something goes wrong in mid-flight. See that section for suggested work-arounds.

VFP provides the SET BLOCKSIZE command to allow you to tune and optimize your use of memo fields. BLOCKSIZE accepts a numeric argument: passing it 1 through 32 creates blocks of 512 bytes times that number; a number greater than 32 creates blocks of that number of bytes. A new option, SET BLOCKSIZE TO 0, stores the memo blocks as individual bytes, rather than as blocks. It seems to us that this method wastes the least "slack space" at the end of each memo, but might in some circumstances lead to greater overhead in processing and reading millions of teeny little blocks. We're not sure where the breakpoint is between the speed of I/O and the speed of the processor overhead, and like many other benchmark items, we encourage you to try it in your environment with your machines and data, to see what works out best for you.



>I am replacing string data in a memo field, without using the replace-additive command.
>
>The data gets replaced, but the table file size increases and increases until the table gets packed.
>
>Thie lage table sizes are causing performance issues, so any ideas would be appreciated.
>
>Thanks in advance
>
>Mike