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