>Hi Hilmar
>
>>>3) Finally, if the index expression says
not accepted, and the expression to be optimized includes
... and not accepted. Since there is an exact match, the index can be used (according to the assumed logic). However, even if this were so, an index created without the NOT will be used in more cases, than one that includes the NOT.<<
>
>Interesting assumptions, but VFP could also specifically exclude "NOT" like this...
>
>AND NOT "NOT" $ indextagexpression
>
>I remember that indexes with FOR conditions don't work by imagining the Rushmore bitmap would not be complete. There'd be less bits than the number of records.
It seems to me that it would be relatively easy to use indices which include NOT. Probably it would also be possible to use filtered indices - by checking whether the filter is relevant for the particular query (for instance, if I have SET DELETED ON, and therefore the implicit condition on "... and not deleted()", an index filtered on "not deleted()" could be used without harm). But that would make the optimization engine more complicated.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
