General information
Category:
Databases,Tables, Views, Indexing and SQL syntax
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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only