Thomas,

I had observed (noted in one of my other notes on the subject) that Select-SQL does run moderately faster with UNfragmented files.

Of course, an unfragmented DBF/CDX does not stay such for long - all new records will again be in fragments. And this condition I did not have time to test.

And of course there can be danger in how a table's pieces (DBF, CDX and FPT) end up on a HD as a result of defragmenting, whether that defragging is a result of PACK or using the DEFRAGMENTER utility. The CDX could end up far way from the DBF and/or the FPT.

My main objective is to change the perception that fragmentation is always bad. My reason for doing so is that I then hope that MS orsome software house can be convinced to make tools to let us do something USEFUL **WITH** fragmentation, rather than always AGAINST fragmentation.

cheers

>Hi Jim,
>
>have you thought abaout the different ways Seek() and Rushmore operate ?
>Your arguments are valid for seek(), but if you have a very large table, which gets written to (into cdx-mapped fields!) and subsequently queried on those fields, rushmore reads the whole index again, since it is marked "invalid". This should be much worse if operating on a fragmented .cdx. The same argument should be checked if querying a large table NOT on cdx-based criteria - then VFP has to read the table in sequential order.
>
>just my 2'c
>
>thomas