>>>Hi Hilmar! Thanks for your reply.
>>>You don't understand my question. The question is:
>>>using a zero records .cdx file, copied over a "n" records .cdx file, with the same header structure, reindexing command after, I will get the same result's that the INDEX command to rebuild all the .cdx file?
>>
>>No - the records are added iteratively, so the indexes are created on the fly during appending the copied records and results are bloat and fragmentation.
>
>Hello Ed,
>
>Would you please expound a little more on this? Are you saying REINDEXing with the existing .CDX avoids bloat, but REINDEXing with an existing (but empty) .CDX file causes bloat?
>
>If so, recreating the index from the index expression itself is the only way to go...

That's correct - creating the index iteratively after a DELETE TAG ALL is the only way to assure that the individual tags within the CDX are contiguous, defragmented and unbloated; if, as in the case of appending records, the indexes are built iteratively, record by record, then all the tags are intermingled within the file - each tags nodes are discontiguous and fragmented. If the top levels of the B+ tree shift, requiring that new top-level nodes be allotted, then there is the potential for wasted space, since the nodes may not be reused for the original node hierarchy (they might be allotted to another set of nodes, so that the block size may be non-optimal, resulting in waste space.)

While it's not a definitive work regarding the algorithms involved in VFP's tag structures, you might do well to read something like Donald Knuth's "Sorting And Searching", volume 3 of his canonical work on programming and algorithms.