David,
Thank you for all of your input. Regarding blocksize, SYS(2012) returns 64. What would be an optimal setting? Regardless, re-working my code to store the individual lines of text into a table and then using the table to build a variable that I can use to replace the memo field in one swoop has greatly reduced any bloating. I ran the same routing and got a 16mb file versus a 350mb file(fpt file)! Packing the memo didn't reduce the size so I think I'm good for now.

Thanks again,
Marcus.

>Marcus,
>
>First off if you are using VFP5 upgrade to VFP6. VFP5 has a bug that prevents memo space reuse.
>
>You can probably fix this by using a better SET BLOCKSIZE when you create the table. Run a query to determine the distribution of your memo lengths.
>
>BLOCKSIZE can not be changed once the table is created so you will have to create a new table and load it from the old.
>
>Are you actually adding the same line of text to every memo field? If so you might want to rethink the way you are doing this.
>
>>I have an app that updates insurance plans. I store some general notes about each plan in a memo field. This field usually contains 7 or 8 small sentences. My problem is that when I populate this information (one sentence at a time) for thousands of plans the memo field bloats to >330 mb. After packing the memo (and 10 minutes) it goes down to 50mb. I'm worried about users running out of disk space. Is there a way to reduce this without stopping in the middle of the routine and doing a pack memo? I update the memo fields with the following code:
>>
>>REPL myMemo WITH ALLT(myMemo)+CHR(13)+cNewLine IN myTable
>>
>>I have also used the ADDITIVE reference:
>>
>>REPL myMemo WITH CHR(13)+cNewLine ADDITIVE IN myTable
>>
>>This gives no relief to the file size issue.