This is interesting. I'd think there is a difference, conceptually, between
an attribute with nothing in it and no attribute at all, kind of like a car
with no gas and no car at all. So, I'd expect the locate to fail - my car
may be useless but I have one. :-)
I guess I learn something new every day.
> Thanks Garry.
> But, if you will refer to another thread here titled : D3 Help Request
> and look at test 2 you will find that the results differ from yours on
> a D3 machine.
> What I have been able to determine is that different flavors of MV
> basic handle this condition differently. Some will return found, D3
> will return missing.
> Which is most correct, and why, I am not qualified to answer.
> I do point out that D3's treatment is at least consistent with AP/Pro.
> That being said, it has disturbing implications, in that the branch it
> takes depends on the data set irrespective of the data being searched.
> By this I mean that given a value search of null, on say attribute 5,
> which is set to null, an else branch (missing) will occur if the data
> set contains less than 5 attributes, but the then (found) branch will
> be taken if the data set contains five or more attributes.
> What this means is that even though you have effectively the same data
> and the same code, a different branch can be taken depending on the
> number of elements in the data set.
> Logic would dictate to me a consistent result. Why Pick operates in
> this fashion, I can only guess. But it does.
> On Thu, 5 Apr 2001 14:20:23 +0100, "Garry Dixon"
> >Check these statements using the variation on LOCATE
> >LOCATE(A,B;POS) THEN CRT "FOUND" ELSE CRT "MISSING"
> >LOCATE(A,B<2>;POS) THEN CRT "FOUND" ELSE CRT "MISSING"
> >Results are FOUND,FOUND
> >The main difference between the two B<2> references is that the LOCATE()
> >version EXTACTs attribute 2 from B before passing the variable to LOCATE
> >whereas the LOCATE SETTING is intellegent enough, or not, to realise it
> >should pass a 2 for the attribute count.
> >Try compiling the code with (A to see the p-code output.
> >> I ran across this inconsistency when porting to jbase from AP/PRO.
> >> Consider:
> >> A=""
> >> B=""
> >> LOCATE A IN B SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"
> >> Then Consider:
> >> LOCATE A IN B<2> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"
> >> In the first example both jBase and AP/Pro say "FOUND"
> >> In the second example, JBase says "FOUND" and AP/PRO says "MISSING"
> >> Apparently PICK thinks that a null dynamic array reference is
> >> different than a null variable, but only if the reference is greater
> >> than 1. Because
> >> LOCATE A IN B<1> SETTING FND THEN CRT "FOUND" ELSE CRT "MISSING"
> >> will produce "FOUND" under AP/PRO.
> >> TWILIGHT ZONE.....
> >> However, why is this even an issue. IF 5 X 0=0, the logic is no
> >> matter what you have on one side of the equation, the result is ALWAYS
> >> the same. You can't get something from nothing.
> >> Hence, how can you find nothing in nothing?
> >> Have a great day!
> >> Clark