Lookup matching problem

[Jaime Perry]

Thanks Bruce!  The index issue was one of my first thoughts. I looked at 
it yesterday, it had the proper field and length but after reading your 
message, I checked again.  Turns out what I looked at yesterday was the 
unqualified index and the one for this qualifier was defined as field 1 
with a length of only 10 not 15.  Not sure why that is but thats a 
different animal.  Thanks again.

Jaime


Bruce Easton wrote:
> Jaime Perry wrote Thursday, June 26, 2008 10:49 AM:
>   
>> I changed the lookup alias from new to test as it was a bit misleading
>> but I am just using the lookup logic:
>>
>>    8  -------   -   -   -   -   -   -   -   -   -
>>       ¦ If:
>>       Then: lookup test = (fn)  k=ky   i=A -nx
>>  9  -------   -   -   -   -   -   -   -   -   -
>>       ¦ If: not test
>>       Then: gosub NEWKIT
>> 10  -------   -   -   -   -   -   -   -   -   -
>>       ¦ If: test
>>       Then: gosub EXISTS
>> 11  -------   -   -   -   -   -   -   -   -   -
>>
>> This appears to work fine for all items other than the DDJNR-2020J-15.
>>
>> There are multiple entries for each item # in the originating file and
>> the thought is to create a new record in our file with the first
>> occurance for a given item # and then add the data from each occurance
>> thereafter to that new record.
>>
>> Jaime
>>
>>     
>
> >From your description of the objective and the lookup line, I'm
> wondering if the value of fn is not as intended at some iteration
> that winds back at line 8.  Have you tested fn with the debugger?
> If fn indicated an unintended qualifier, then maybe the indexes of
> that qualifier need rebuilding/have the wrong length?
>
> Also, I would say, for something I always check in a case like this,
> to verify that the intended length of the key ky is not declared
> with a shorter length, as in automatic processing.  But you did say
> that you started with field 1 as the key, so if field 1 is the correct
> field, and you still have the problem, then I would more suspect
> an index length/corruption issue.
>
> Bruce
>
>
> Bruce Easton
> STN, Inc.
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20080626/9219be80/attachment.html