FPD did not have views :-).

>Ok, it seems that the consensus of the majority is that a tag on DELETED() is UNbeneficial a lot more often than it would be beneficial. Then the one outstanding question, I believe asked by Jim N., is this: Were the original findings back in the Fox DOS days wrong to begin with or has something changed between then and now to affect the usage of a tag on DELETED()?
>
>Thanx
>
>>Colin, et. al.,
>>If these SELECTs were done with NOFILTER, or the equivalent, fine. But if you're measuring the time for a filter to be set, that's no good. I have a class that generates test data on my web site. It's referenced in the Rushmore article. Test it yourself, but please understand what your testing.
>>
>>This isn't a believer/non-believer thing. It's not that hard. Rushmore reads the CDX. If the size of the Deltag portion of the CDX which points to the undeleted records is larger that the size of the actual deleted records read, it's not good. If it's smaller it helps. It doesn't matter if you are using Views, or doing REPLACE FOR RushCondition. It's the same with any index!
>>
>>
>>>Jim,
>>>
>>>I find all this very confusing/frustrating at times because I look at the results reported by Andrew and then I do some simple testing that gives the opposite results. Test was mytable with 37000+ records and no index tag on DELETED(). I ran SELECT * FROM mytable 3 times in FP2.5 DOS and VFP6 SP3 and FP2.5 results were 5.11, 3.95, and 4.39 seconds and VFP results were 1.14, 2.39, 1.55 seconds. I then added a tag on DELETED() (about 2000 records are deleted) and the results were FP2.5 0.05, 0.01, and 0.00 seconds and VFP 0.01, 0.00, 0.01 seconds
>>>
>>>So for this scenario I can say VFP is generally faster than FP2.5 and the DELETED() tag was a benefit to both. But, this obviously can't be a blanket statement because in some cases it has been reported as detrimental. So how are we to know when to use it and when not to?
>>>
>>>>Thanks for that Andrew.
>>>>
>>>>It still baffles me that exactly the opposite used to be reported - a slow response would become lightening fast when a TAG on Deleted() was ADDED.
>>>>
>>>>Still smells to me (that something changed sometime ago).
>>>>
>>>>Cheers,
>>>>
>>>>Jim N
>>>>
>>>>>I can give you a real-world example of my playing with the DELETED() index. A few months ago I was reading here the debate on using a DELETED() index tag and decided to give it a shot and see how it worked. Just 2 weeks ago, I was desperately trying to figure out how to speed up a form that uses a parameterized view to fill a simple grid on this form. The view has only 1 table (around 20k records, < 5% deleted) and 4 filter parameters. The application is networked.
>>>>>
>>>>>I remembered the DELETED() tag in the table and took it out. The requery time went from 28 seconds to 11 seconds. No other changes in the tables/views or program code. The speed difference of adding a record wasn't really noticable.
>>>>>
>>>>>
>>>>>- A Hilton
>>>>>
>>>>>
>>>>>>>I think it would be very interesting to see the tests that convinced Walter and yourself of the relative uselessness of the DELETE() tag performed in Fox 2x. I do not (and never have) own a copy, so I can't test myself.
>>>>>>>
>>>>>>>But if you are correct, and something changed along the way to negate the benefits of DELETE() tags, performance differences should be pretty evident.
>>>>>>
>>>>>>
>>>>>>Just a point about testing: it should be done on a network. From my investigation when you update a table on a stand-alone machine the Rushmore bit maps are not reloaded. (Presumably they are just updated.) On a network if any workstation changes the table then every (other?) workstation must reload the Rushmore bit maps including the deleted() map.
>>>>>>
>>>>>>Peter