Andrew,

Deleted() tag hurts views because view is NOFILTERed cursor. However, if you do ad-hoc SQL-query to get FILTERed cursor then the results will be quite opposite. It's exactly the point: deleted() tag is dangerous if application is blindly based on views.

>I don't know about the past (before VFP 6.0) because I never used the deleted() tag before the 6.0 version. But I was reading the below posts on this subject and decided to do a little (very unscientific) test on my development machine with the same table/view/screen/grid that I mentioned in my previous post.
>
>My previous post mentioned that I had a big speed improvement when I took out the deleted() index tag from the table from which the view was based on. This was for a networked application. JUST NOW I tested it all locally (my development machine) and found pretty much the same improvement when the deleted() tag *wasn't* there. Both (with and without the index) were considerably faster when it was all local though. One thing I did notice here is that after the first time doing the requery() the results were returned very quickly (as compared to the first time after shutting down VFP and either adding or deleting the deleted() tag. I'm assuming this was caused by the file cache getting into the act after doing the first requery().
>
>So, to sum it up, I've found that (at least in this particular case) the deleted() index tag hurts the performance on requery's. I had assumed that the deleted() tag would have helped and not hurt (which is why I originally put them there in the first place!). If anybody comes up with a case where it would help then please let us all know. I'm all for speed!
>
>- A Hilton
>
>
>>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