Jim


>.... And, of course, the Help says that the FPT WILL be handled too, and that in itself might be a major reason some of us run PACK (the better organization being a beneficial side-effect).

IMO "better orgnaization" is not implied in any way in the VFP documentation for the PACK command. I suspect that the PACK simply writes the non-deleted records in record number sequence to a new file. This may or may not be the "better organization" depending on the application. I dont think its the function of PACK to attempt to answer that.


>...Yes, it is the OS that physically writes, but VFP has a MAJOR impact on it.

I repeat I am not expert in this but I dont see why VFP should have any "major impact" on the writing process at all. The way I understand it VFP passes the data it wishes to write to disk to the OS which will handle the how, when, and where by its own set of rules - which need to take into account all the other things going on as well.


>Should the DBF be bigger than the RAM can sustain, then VFP will tell the OS to write out (the length of) what is currently in RAM, resulting in a 'fragment' for that part of the table.

Whether any particular write results in a fragment will be, I think, entirely dependent on the OS and the state of the HDD. Not on VFP. I think VFP will best attempt to minimize writes by good use of memory but when the final instuction to write comes its over to the OS which has its own agenda and rules.


>The conditions for a .FPT are more mysterious than what I described earlier for the DBF and CDX. I have run over 100 tests involving .FPTs and EVERY TIME the .FPTs were ALWAYS 'fully' fragmented. In other words, I could create circumstances where the .DBF and the .CDX was minimally (or not at all) fragmented but in NO CASE would the .FPT be similarly built!

The DBF and CDX files are all fixed length records whereas the FPT file will not be so. It effectively contains variable length data and VFP might pad its data to try and anticipate future additions to the data. Also records in the DBF file are always added sequentially while data in the memo fields is written randomly.


>Given all of this, **my** view is that many (most?) expect a PACK to copy the table, rebuild the indexes and 'optimize' the .FPT in ALL circumstances and it should do so.

I disagree Jim. Optimization is not implied in the documentation. Only the removal of deleted records and redundent space in the memo field. Optimization is a complex issue which involves (amongst other things) the optimal ordering of the table itself, which VFP cannot know, and the optimal storage of the file on the HDD.


>Failing that, then the documentation should be revised to explain what may happen, depending on circumstance, including the factors that determine the 'optimization' (or not) of the .FPT.

The only thing I am curious about is what the rule(s) are that VFP uses for packing the memo field. But its only a curiosity - I can live without knowing :)