>>>>>>I just found to my surprise, that EMPTY() is NOT a Rushmore optimized function. Why is this? I would think this would definitely be supported.. Anyways, is there a faster/cleaner/better way to do the same thing in my Rushmore optimizable expressions other than FIELD=SPACE(8) or FIELD != SPACE(8)? ISNULL() only works if you set your DBF files up with a null value, I believe-- and I need to retain backwards compatibility with other DBF files. Thanks for any help.
>>>>>
>>>>>

---

field == ""
>>>>
>>>>'==' means exactly equal-- equal in character length. A character field with 1-255 characters will never be exactly equal to a zero-length character string. I could use FIELD == ' ' with the neccessary spaces inside, but that's extra work to find out the size of each field I need to evaluate. FIELD=" " would work better, but if the character expression starts with a space, that would cause a problem. I was looking more for a universal function that could be used(at least for strings-- preferrably numeric as well) that was Rushmore Optimizeable-- just to evaluate if the FIELD was empty(the FIELD **always** has a length, however).
>>>
>>>

---

Yes Derek,
>>>It means exactly equal, and both sides are "padded to same size" before comparison. That's if your char field is n length, right side would be space(n). A Rushmore optimizable empty(field). !(field == "") would correspond to !empty(field). Just try it with any table :
>>>
>>>select * from mytable where myCharField = ""
>>>
>>>select * from mytable where myCharField == ""
>>>
>>>return different sets where latter returns the records that empty(myCharField).
>>>field == "" is Rushmore optimizable but not !field == ""
>>>
>>>

select * from myTable ;
>>>  where pkfield not in ;
>>>  (select pkfield from myTable where myField == "")

>>>is Rushmore optimized version of !empty(). But of course for the latter you might want to use a shorter Rushmore optimized one :
>>>
>>>select * from myTable where myField # space(fsize("myField","myTable"))
>>>
>>>Also there is another option that might be the choice in this situation and fully Rushmore optimizable :
>>>
>>>set ansi on
>>>select * from myTable where myField = "" && empty(field)
>>>select * from myTable where myField != "" && !empty(field)
>>>
>>>("set ansi" effects SQL not "set exact").
>>>Cetin
>>
>>

---

>>
>>Well, this works great with select statements, but all my FOR statements(SCAN,SUM,COUNT,AVERAGE,etc.) don't respect this funky way of doing things. I got around it temporarily by simply using 'TRIM()' on the field, but I'm sure that isn't the best thing for speed. LMK if you have any ideas. Thanks.
>
>

---

Derek,
>Then I would provide an empty value for right side :
>

use myTable
>scatter memvar blank
>scan for myField = m.myField and ...
>endscan

Cetin

Not a chance I can use scatter memvar-- too many possibilities of global memory variables of the same name-- the other programmer here was using that without my knowledge, and he had a time trying to figure it out. Why doesn't scatter give you a choice as to what fields are scattered, and to what memory variables? I've tried to do this numerous times with no success...