>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.
I think it's only our perception of the matter that has changed. Those who knew that tag on deleted() was always good were thought to be gurus... and nobody questioned this. To add, the sys(1031) or whatever was the exact
name of the "show me the optimization" never said "full" without it, which added to the belief. Nowadays, we're all a couple of years older, and hopefully wiser.
>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'.
This narrows down to the question that if Set("deleted")="ON", do SQL queries have to read the table physically to check for deletion marks? Do they have to do it each time? Or do they do it only over the result set? Seemed to be that having a tag on Deleted() would help, and it probably did in many cases - but then, the rule is not sacred anymore. Exceptions have been found... so, OK, one deity less.
>I wish that some satisfactory explanation could be discovered for this.
I just want to know does VFP's SQL read the deletion mark of all the records, or only the retrieved records. That would make a difference. BTW, how come nobody mentioned this tag in 2.x? Not that I can remeber.
