Walter,

>This depends on the resultset that is the result of the optimizable expression returned by the optimizer (because of other usable indexes). If the optimizer returns only about 100 records, the selection the lastname field does not have to have a index on it as VFP is fast enough to select the right records among these 100 records.
>
>As I have stated before it depends on the seletivity of the index. An index in which an indexvalue selects only a small amount of records is far more usable than an indexexpression which contains only a few different values and return a large amount of records.

My point here is that if one does not know the size/scope of the result set, it could be very small or quite large (the user selects the fields and search values), so the index is required on a large table....

>I think you're formula should be a guideline to let the developer himself decide if the gain of performance is big enough to use the index on deleted.
>The actual gain would depend on many factors like, width of the index, fragmentation of either the table or the index itself, internal memory, Harddisk, CPU etc. I don't think it is possible to determine an exact point where it would be wise to add an index.

Agreed, a rough guideline only, and not the only factor.

>Personally i think (again theory) that above the 10% - 20% you would notice the benefit of the tag in queries.

Sounds reasonable to me...