Hi Craig,

While your response is not in dispute (from here anyway) at all, I still find myself to be a minority of 1 in worrying about WHEN (and WHY) this (may have) changed. Personally, I'm still convinced that it WAS changed.

The MSDN (??) Article of Oct.96 titled "Performance Tuning Tips for MS VFP", the Hacker's Guide and others that I cannot cite at this moment all state directly and without reservation that an index on DELETED() will improve performance (I will grant that DELETED ON is stated or implied) of any SQL query.
FPA Tips and articles have mentioned this too (until THAT article) and a whole lot of people here on UT, on being told to do so after complaining about poor performance have reported back that 'things now are flying'.

Christof L. had some reasonings as to why we are likely seeing differences now, but those do NOT really answer the case that today even a "traditional" deployment of a SQL statement (no view, no dialup, etc) shows the impact of a TAG on DELETED() rather than the (previous) benefits enjoyed.

I wish that some satisfactory explanation could be discovered for this.

Jim N

>>Hi all,
>>
>>The VFP 5.0 Developer's Guide states at page 396, parag. 5, " Avoid using indexes on fields that contain only a few discrete values such as a logical field"
>>
>>So then why should having an index based on deleted() be considered indexing effectively using Rushmore (see DG page 400)
>>
>>Aren't these two very similar in their respective context (i.e.: few discrete values .T. or .F.).
>>
>>Why should it be OK for deleted() and not for the other(s)?
>>
>>Thanks
>>
>>Pierre Richard
>
>As a general rule, if your table will have mostly added data and modified data (very few deletes), the tag won't help. However if you will be deleting lots of data, a DELETED() tag will help. My experience is that the large majority of tables have very few deletes.
>
>BTW, if you are trying to understand Rushmore, have you looked at the article on my website?