>>Edward,
>>
>>>There are few minor uncertainties in your conclusions. The main one is that it's really difficult to predict what is 'few' deleted records means and when/where this limit will be overcome and lack of Deleted() tag will become more visible.
>>
>>As i stated there SHOULD not be many deleted records in a large table. There where it is impossible to keep the deleted rate low, it COULD a solution to use a deleted index. Only by testing this you could determine if the performance would increase by an index
>>
>>>Also, VFP does not take whole index to memory, if it would be so, it just could not work with large tables on network.
>>
>>I did find some documentation that rushmore only works when the whole index is in memory. Though this was regarding FPD/FPW 2.6 (page D 17-2) i suspect it still will matter in VFP.
>
>Walter,
>Testing is necessary part of development process, but it's impossible to simulate real situation 100%, because of many reasons: network traffic obviously will be different, number of deleted records may vary significantly during the system life span etc.
>In regard to Rushmore: it seems that nobody knows exactly how it works, but assuming that some real index files are tens MB on network, one can say that moving whole index to local computer (hard drive in this case) and only then starting processing is not the way Foxpro actually works. I remember some highly interesting UT threads on this topic, and most people settled that only part of index travels over the network. I don't want to say that majority is right just because it's majority, and I understand that performance in many situations may be tuned without Deleted tag, but the same is right for the opposite case, i.e. tuning is also available when Deleted tag exists.

The original Hacker's Guide had an excellent discussion of this topic. If anyone reading this thread has the new edition of the book, perhaps they'll post an update on what it says.