>>>>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").

OK. This is freaky. Before I responded before, I opened a file(all in command window), and did a ?ORDER->NAME=="" on an empty record. I got .F. After this reply of your's, I tried the same thing except with a SELECT SQL statement, and it does exactly what you say it does-- why the inconsistancy in VFP???