Graig,

>There have been many long discussions about this here on the UT. I think the decision was that you may get a performance increase by having an index on DELETED() then adding WHERE NOT DELETED() to your query.

As I pointed out about 6 month back, the deleted() tag is not helping in most situations. Only in a few limited cases you would have any benefit. In other cases described in one of the Fox Advisor articles, the deleted() tag can hurt performance very much.

Another issue is that this solution does not lead to smaller index files. You even have to add another index (the deleted tag).

If we want to ingnore the existance of deleted records, it makes sense we don't index them eiter. This leads to smaller indexfiles which can be processed by rushmore a lot faster. This request will lead to improved performance in many cases. Isn't this all what we want ?

Since most VFP developers use the SET DELETED ON setting, it would really a big help. How many people don't ask why they can't add a new primarykey value because there is already one in a deleted record? To me it does not make sence (if you consider deleted records as non-existant records) that the thing works like it does now.

Of course we can point out the culprit: VFP stills hold deleted records physically within it's tables. Another wish that would solve the problem is to physically delete records out the table whenever a delete is isued. But I suspect this would have more impact than the wish for optimizable indexes scoped to nondeleted records.

Walter,