>>>>>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???
Derek,
You're right. If it's not SQL both sides must be the same size. I don't know why FP team did it like that.
In documentation if you look for "==" this is documented like this. But if you also check "set ansi" and "set exact" you'll see "==" operator is documented different for SQL and nonSQL comparison.
BTW coming from Clipper or Foxbase (noticed -> :) ?.
Cetin
