>>I re-added the index for the Upper( D40DirNo ) and I got a result of .6
>>I re-added the index for the Left( D40Acct,2 ) and I got a result of .6
>>I re-added the index for the Upper( D40Audit ) and I got a result of .7
>>I re-added the index for the Empty( D40CkNo ) and I got a result of .8
>>
>>It looks like the last 3 indexes which in this particular select and return
>>the majority of the table actually, slow the performance down.
>
>I think the only indices that can either speed up or slow down a query significantly are the ones whose index expression is part of your query expression - including the implicit "DELETED()".
>
>A time difference of 0.1 or 0.2 seconds seems to me to be under the "experimental uncertainty". Either stop worrying about it, or try with a larger data set (or with a repeating loop).
>
>Relevant questions, I think, would be: what is a typical index expression like (if I remember correctly, they can change dynamically, depending on user options)? Do you typically combine conditions with AND?
>
>Please note that a condition like "D40DirNo > 100", if it is combined with another expression, is better NOT Rushmore Optimized, because of the large number of index keys returned.
>
>Hilmar.

The results were repeatable. I ran the tests about 20 times and came up with the same results. As far as web pages go the .1 or .2 difference can make the difference between a successful site and an unsuccessful site.

In the case of the returning a large number of index keys, I agree. This is exactly why the last two conditions were slower because they returned nearly the entire table.