>>>I'm pretty sure that filtered index are not Rushmore optimisable. So that would make it slower. Do you have an index on SearchTB?
>>>
>>Right now I just have an index on SearchTB. I'm thinking, do I need to try to optimize the rest of the expression, e.g. have an index on empty(InsCommand) as you suggest or use the scan for as it is or do the check inside the scan...
>>
>>Or use the "scan while" technique and use filtered index.
>>
>>I just can not test every possible scenario, and these tests are very costly...
>>
>>>>I'm thinking, could it be better to use filtered index instead.
>>>>
>>>>E.g. currently I do:

>scan for m.plError=.f. and SearchTB = m.lcSearch and not empty(InsCommand)

>May be it would be faster to set a filtered index and do seek, when scan while?
>>>>
>>>>However, as I recall, I tried similar idea (in another context, though) and it actually slowed it down.
>
>O, I see, you want to use something that will speed that SCAN.
>I don't think that SCAN FOR is optimizable
>scan for m.plError=.f. and SearchTB = m.lcSearch and not empty(InsCommand)
>What about:
>

>INDEX ON SearchTB TAG SearchTB
>SET ORDER TO
>SCAN FOR SearchTB = m.lcSearch
>     IF .NOT. EMPTY(InsCommand)
>         .....
>     ENDIF
>     IF m.plError
>        EXIT  && Favorite for some members of the UT :o))))))
>     ENDIF
>ENDSCAN
>

I'll try that. So far it seems to me that every time I touch this damn thing and try to optimize the code using lots of "genious" ideas, the output result is completely different, e.g. it becomes slower and slower.

E.g. today I added three new fields called UpdCommand, InsCommand, DelCommand, so I can skip some of the logic I was previously using. But I do not see a speed improvement, quite contrary :(