-- EMPTY() has never been optimizable and I doubt it ever will be. --
Sadly I'm sure you are right Mike.
It reminds me of Locate vs Go Top. You'd think they were the same thing.

After all these years it still seems dumb to me.
But it is what it is and at this point, and I'm sure you are right, it will never change.



>>>That's just how engine works. I don't think there is anything wrong here as long as it is documented.
>>
>>I know that and I know it is not a bug. I just think it would be VERY nice if the engine could figure it out and optimize it. Or I guess in the help file topic for BETWEEN and EMPTY there could be a note something like "You shouldn't actually use these functions because they stink!"
>
>They don't stink. We need to know how Rushmore works. It optimizes using the field name(s) to find the index(s). m.ldDate is not a field.
>
>For years people thought BETWEEN and INLIST were not optimizable, but they are. BETWEEN(fieldname,value1,value2), INLIST(fieldname,value1,value2)
>
>EMPTY() has never been optimizable and I doubt it ever will be.
>
>
>>
>>
>>
>>>
>>>>With index tags on Mem_dEffect and Mem_dExpire this is fully optimized:
>>>>

>>>>SELECT * FROM MEMBER WHERE MEMER.Mem_dEffect<=m.ldDate AND MEMBER.Mem_dExpire>=m.ldDate
>>>>

>>>>
>>>>It would seem either of these two would be fully optimized.
>>>>

>>>>SELECT * FROM MEMBER WHERE m.ldDate BETWEEN MEMBER.Mem_dEffect AND MEMBER.Mem_dExpire
>>>>
>>>>SELECT * FROM MEMBER WHERE BETWEEW(m.ldDate, MEMBER.Mem_dEffect,MEMBER.Mem_dExpire)
>>>>

>>>>But with these optimization is only partial. Couldn’t you make the engine smart enough to figure this out and fully optimize it?
>>>>
>>>>Also
>>>>

>>>>SELECT * FROM MEMBER WHERE MEMBER.Mem_dExpire = {}
>>>>is fully optimized
>>>>but
>>>>SELECT * FROM MEMBER WHERE EMPTY(MEMBER.Mem_dExpire)
>>>>is not.
>>>>

>>>>
>>>>Again, couldn’t you make the engine smart enough to figure this out and fully optimize it?
>>>>
>>>>
>>>>Thanks,