Hello David.

Thanks for the quick description of memo defragmentation. I knew pointers were all that was stored in the DBF, but I never really thought about what was done with the FPT files when memos were edited. If it wasn't done this way, the FPT would have to have a pointer to the next fragment of the memo when memos were edited to larger than original. The way it is done, memos just need a start (pointer in the DBF) and an End of Memo character.

Just a note: PACK w/o the MEMO or DBF clause will also PACK the memo file (according to the VFP 5.0 Help System).

Take care,

Joe


>>Hi Marcus,
>>
>>>My first thought was to use memo fields to allow the support person to log in all the information. However, I've heard a lot of talk about memo bloat, which makes me think twice. Is this a situation where memo bloat might occur? Is it that severe of an issue?
>>
>>I don't think you should put all your info in memos, your table could be laid out like this:
>>
>>Company-C
>>Phone-C
>>Category-C
>>SubCategory-C
>>Handled By-C
>>TimeStarted-T
>>TimeStopped-T
>>TimeBilledFor-T
>>Billed-L
>>Notes-M
>>
>>You should have a memo field for notes. But everything else could just be regrular fields. Just my opinion.
>
>First, I agree with Mike, you should use regular fields for most things, and memo fields for notes or text.
>
>Second, will you have trouble with memo bloat? Here's how to know. If the text in memo fields is edited frequently, you will have to deal with growing memo files. As you probably know, the DBF holds a pointer for the location of the memo int the FPT (memo file). When you change a memo and save it, FoxPro just tacks the entire text on to the end of the memo file and updates the pointers. This way you don't suffer with fragmented memos which will slow processing, like fragmented files do on your computer. The trade-off is memo file bloat.
>
>If you store text, display it, but rarely change it, you'll have no problem. If you do suffer memo bloat, though, the PACK MEMO command will take care of it.
>
>David.