odd lookup problem

[Richard Kreiss]

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.

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.

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