odd lookup problem

[Bruce Easton]

On 11/8/10 2:55 PM, Richard Kreiss wrote:
> Sent 3 code listings a few minutes ago to Ken and the list.
>
> 1. Original code with exact lookup
> 2. Modified code using lv and a get lowest
> 3. Working code
>
> See below
>
>
>>> Richard
>> On line 193, why are you using 16 instead of the key 'lv' that you assigned
>> right before that?  In any case, with too many unknowns and too many things
>> changing at once as Ken said, I think it's impossible to determine what could
>> have caused the behavior you already seen.
>>
>> But to answer your last question, I would say because you should always
>> have that 'not' test.  There is always the chance that the lookup (of any type
>> of match) will not match anything on file and you should provide for that.
>> Otherwise, in this case, if you didn't have the 'not'
>> test, you may get a filepro error on the next line since it references a field
>> ('sales(3)') on the if line.
> The reason for no NOT test was I wanted the code to drop through if no sales journal record was found and branch only if there was a record found.  Hence testing for SALES first.
yeah, but you can't do it that way (just testing for SALES first) - or 
you might get a filepro error.  if the lookup is unsuccessful and you  
are testing if: SALES and sales(anyfield#) - you will get an error. So 
-always test for NOT first whenever you know you're going to then 
reference a field# from the lookup file in any way.

But now anyway - it's good you have the not test.  And by the way, that 
makes the If: SALES part of your next test superfluous.
> I just find it odd that even when a record is present, I was looking at the record which should have been found in the sales journal as I wanted to check the journal # in the debugger, the lookup showed up a false until the not sales was place above it.
Impossible to say without all the debugger output as you move through 
this section and being able to see data as well.  But if your 'not 
SALES' test after your lookup... -nl is evauating to true in the 
debugger, then no data was matched by the lookup and that doesn't sound 
abnormal.  You'd have to show with data and all the key value at lookup 
time to show that it seems incorrect.

Bruce
> Richard
>
>
>> But as to why it is or is not matching when you think it shouldn't or should,
>> respectively, I believe you'd have to show what the debugger is showing for
>> the value of the key and any successful lookup (joining) fields from the
>> lookup file, as well as the debugger's true/false values, starting with the
>> lookup line and onward through the tests that follow (that reference the
>> lookup file/alias).
>>
>> Bruce
>>
>>
>> Bruce Easton
>> STN, Inc.
>>
>>
>>
>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>