I am well aware of the article from May '99 FPA, and I realize that using Deleted() tags isn't always a good thing. But, frankly, I seen cases where deleted tags have significantly helped. I think you're being a bit harsh in refusing to even try then for this situation to see if they'll make a difference. Since all the other tags required are there, it is certainly worth trying to add deleted tags to see if they make a difference.

>Barbara,
>
>Don't ever, ever add a index tag on deleted() without the specific need of it. In this case it will propably hurt perfromance bad.
>
>This is a general misunderstanding. A deleted() tag won't speed up your queries if they don't contain significant amounts of deleted records. When on a network a deleted() tag can hurt performance very bad. There is a MS knowledge base article about this issue, and a FPA article (may or april 1999).
>
>When querying a single record (with the use of a primary index) out of a large table (1 million+) you'll see what I mean. If a DELETED() tag is present it will take more than thousand percent more time to finish the query than without it. It has to do that the DELETED() tag adds no value to the info already in other indexes and in a large table all indexnodes for non-deleted records have to be processed also.
>
>Only in specific cases where:
>- You have a significant percentage of deleted records and the tablesize is more than a thousand records.
>- You want to optimize a COUNT command
>- You want to produce filtered SQL results. (You might be better of with SET FILTER without the deleted TAG)
>
>it might speed up rushmore, in all other cases it can only hurt performance and won't enhance any.
>
>TIP: Delete all your DELETED() Tags in your project and watch the results. If there are large tables involved you'll notice the speed increase, esspecially on networks.
>
>
>Walter,
>
>
>>If you have SET DELETED OFF and SET ANSI OFF, you probably need tags on Deleted() for each table.