>>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.
>
>Well I don't know. The Hacker's Guide suggests that it does read each. I know from experience (FPW 2.6) that I had a two field table with an index on a single field and when I accessed that table using the index and only referencing the key field in the logic it still went to the physical records.
>
>I'm still very suspicious about the current situation - how could so many people (guru and 'normal') SEE an improvement then. How would they actually know that performance is now degraded with current VFP (in the general case)???

OK, Jim, for a while I thought my imaginary story may pass as consistent... can I try to patch it?

It's only the rule that TOD (tag on deleted()) will always speed it up that's demythologized. It helps in only 98% of the cases, or so - but the 2% seem to be recently discovered (after the article, and couple of months of discussion here on UT). The cases which fall into the 2% seem to be those when a table already has many tags, the result set is relatively large, the table is large, and the tags involved take a large chunk of memory to process. Then, using up extra memory to check the TOD seems to add overhead - this memory may better be used to speed up other processing, make bigger buffers for other tags etc.

As we actually know very little of Rushmore's intestines, I don't see why would my SWAG be smarter than yours :). Still, considering Christof's message in this thread, it seems to be that having no TOD on a large table with many indexes and a small result set may be faster than loading the TOD; in many other cases TOD serves good - VFP doesn't have to parse the result set to check for deleted records then. It seems to be we only got one "firm rule" converted to the more common "it depends".