Hi greg,

If SET DELETED = OFF, then the indexes on deleted() are not used at all in rushmore optimization. The .NOT. DELETED() clause is not rushmore optimizable since the .NOT. operator prevents that.

It seems that AccPac circumvents the performance issues this way and only used the DELETED() index for particular cases where SET DELETE = ON or when a SEEK is used.

Walter,


>Greetings,
>
>A few weeks ago there was a thread concerning the harm or value of creating an index on DELETED(). I was very interested in this because AccPac Pro Series puts a deleted() index on every single table in the system. The overall concensus was that this would be a performance penalty and that I should be able to remove the deleted() indexes altogether.
>
>This week I started looking into that and have found another wrinkle. 90% of the queries in AccPac Pro Series include .NOT. DELETED() in them. In other words AccPac does not set deleted on, they omit deleted records in each query specifically. So now I wonder if I remove the deleted index will I not have a performance penalty on the large tables because the query will no longer be optimizable. Obviously there is no way I can go through all the source code and change all the queries so is the best thing to just leave the deleted() indexes in place?
>
>Greg