Hi Walter,

>I did base this on the theory (with the use of some practical examples) which i did try to explain in this thread and in the tread 'TAG ON DELETED() ..... HUMBUG'

No, you didn't. *s*

All you were showing where SELECTs based on a single table where you need all fields on a nonfiltered cursor. In this case, a tag on DELETED() might not be necessary (and you still can control this with SET OPTIMIZE). But I don't always want a physical table, I'm pretty happy with a filtered table in many cases.

And, more important, you haven't yet proofed you theory with multi-table selects, and that makes up many Selects in a typical VFP application. Let's say

SELECT A.* FROM A, B WHERE A.ID == B.ID AND B.Field == "Value"

I have an index on A.ID, B.ID and B.Field. In that case, VFP has only to access the indexes for both tables and the selected records in table A. Without a index on DELETED() in table B, it has to read ALL matching records in table B. Believe me, that can slow down a query quite a bit, especially on a slow network.

The recommendation to use an index on DELETED() is not based on an assumption one developer made years ago, it's the experience of many developers that it speeds up many _real_ queries in _real_ applications. It might make a query slower in some cases, which is still under you control by SET DELETED OFF and adding WHERE NOT DELETED(), or by turning Rushmore off with SET OPTIMIZE OFF. But overall, it's faster.

Christof