Hi Marcus,

Because of the way memo fields are created and maintained, if the contents of a memo field is replaced with a string that is longer than the first string, the first area of the file is abandoned and the string is written to the end of the memo file and the pointer to the string changed in the dbf appropriately. Thus the bloat!

You might be able to 'fool' the memo file by creating the initial string padded with a large number of blank spaces. Try this, if you think the average memo field will be 1000 characters, create a 1000 character string by right padding the string with blanks. Then to add a new line, trim the contents of the memo append the new line, and then pad back to 1000 characters. This should allow the memo field to simply replace the old value with the new value.

Mike Antonovich


>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.
>
>TIA,
>Marcus.