>Hi, Jim!
>
>Nice observation. However... HOW you recommend to solve this problem? FPT file defragmentation on logical level is needed for speed purposes when working with a single record. ON the system level, I think it would be too hard to control, if possible at all.

I do NOT see a way of solving this at this time. But getting some utility capability to manage fragmentation to our own advantage would be a giant step. Towards that end I have started a Wiki topic.
I see the first challenge as getting people to acknowledge that applications like VFP - and really any application that uses multiple (like 20+) files simultaneously and has record insertions into many of them done from seveal sources 'concurrently' - benefit from fragmentation. I believe that this would give software houses, and possibly MS itself, the incentive to make a useful utility.
I understand that the NTFS file system has capability for user add-ins and the designation of user data areas within the file system. I can see these types of things being exploitable for this purpose.

>
>I think this should be just better docummented in the help files. So, when working on level of single record, leave it as is. When doing time-consuming data processing, make PACK first, and then proceed.

I agree that we need more/clearer information in the Help. But be surprised (as I was) that a PACK or PACK MEMO does NOT result in a defragmented .FPT file! It does get de-bloated, I assume, but the Disk Defragmenter "Analyze" shows that it remains fragmented (but with fewer fragments) after the operation.

>
>In addition, in many our production applications we have automated administrative/maintenance tools running and making PACK and full REINDEX of every table, check for data integrity and corruption issues etc. I think, if MS would make such utility in tools for next version of VFP, it would be VERY valuable.

Yes, I agree. But this is a separate issue, and be aware that a PACK and/or a full REINDEX will result in a defragmented DBF and CDX (just not the FPT). The PACK will do so, as I learned recently, only if there was at least 1 record deleted during the copy operation it does internally. If no records are dropped then the copy of the table is simply deleted and the internal REINDEX is skipped. However, the FPT processing is still performed.

cheers

>
>>WARNING - long-winded diatribe following. . .
BIG snip