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

---

Derek,
>I don't know if "==" behaviour will change in VFP7 or not. I don't think it will because FP team is in the habit of supporting backward compatibility and they should be.
>"Scatter memvar" lets you choose the fields and furthermore it lets you to scatter them to a new object with a "name" clause :) This would free you I think. BTW many commands including "browse" support "name" clause.
>

use myTable
>scatter fields myField1, myField2 name "oRecord" blank
>scan for myField1 = oRecord.myField1 and ...
> *code
>endscan

Cetin

Thank you. I think this will finally be a viable solution for my purposes. Thank you very much!