lookup problem

[Bruce Easton]

Richard - ok, so you're saying field 16 should have the same value as 
"lv" from your test file.

But if you're getting different results between d/rlcerk, then I would 
think that should be your first concern.  Either 1. your tok isn't built 
from what you currently have in your prc, or 2. your dclerk is a 
different version from your rclerk, or 3. your environment/target 
'neighborhood' is somehow different between how you're calling 
dclerk/rlcerk - either for the executable itself, or for the area of 
databases they are looking at, or 4. your not allotting enough "t" size 
for tok to run with (but I think your error would definitely be 
different), or 5. there truely is some but in fp.     I'll bet  that if 
you're truely seeing different results between d/rclerk, then it's 
either 1/2 or 3 from above.

Bruce


On 8/4/10 1:47 AM, Rkreiss at verizon.net] wrote:
> Bruce,
>
> I know what field 16 is as I am sitting on that record.  The problem is that the same program  bombs in dclerk and not rclerk when sitting on the same record.  I access this record by record number so I am always test againt the same record.
>
> However, I will verify the value in field 16 on the AM.
>
> richard
>
> -----Original Message-----
> From: Bruce Easton<bruce at stn.com>
> Sent: Tuesday, August 03, 2010 11:12 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: lookup problem
>
> (Inline comments below - Bruce Easton.)
>
> On 8/3/10 6:16 PM, Richard Kreiss wrote:
>    
>> -----Original Message-----
>> From: Kenneth Brody [mailto:kenb at fptech.com]
>> Sent: Tuesday, August 03, 2010 5:16 PM
>> To: Richard Kreiss
>> Cc: filepro-list at lists.celestial.com
>> Subject: Re: lookup problem
>>
>> On 8/3/2010 4:35 PM, Richard Kreiss wrote:
>>
>>      
>>> I have a program which looks up from on file to another using index c in the
>>> second file.  The lookup was coded for the get lowest, using the master_code
>>> and a sequence number(NN).  Lv=master_code&sq. The lookup kept failing with
>>> record not found.  It even failed with just the master_code.
>>>
>>> When I check the second file using the master_code, the record came up.
>>>
>>> Each time I tried to get this lookup to work, it failed.  I created an @key
>>> routine in a test file using the same lookup code and it succeeded.
>>>
>>> I finally gave up with this routine and changed the lookup to a browse in
>>> descending order.  There are 2 records in the second file matching the
>>> master_code.
>>>
>>>        
>> [...]
>>
>>      
>>> *** A filePro Error Has Occurred ***
>>>
>>> On File: C:\appl\ccp/filepro/transaction/index.A
>>>
>>> Input Processing
>>>
>>> Line Number: 450
>>>
>>>            rn=sales(@rn);GOTO lok_sjn
>>> ^
>>>
>>>            @bk = "s"
>>>            rn=sales(@rn);GOTO lok_sjn
>>>
>>>        
>> [...]
>>
>> What is the exact lookup statement?
>>
>>    What is the exact value of the key used in that lookup?
>>
>> How, exactly, did you "check the second file using the master_code"?
>>
>> IUA to sales_journal, secect screen 1, (4) select index C, type in 1003-10005 press<enter enter>
>>
>> master_code(field 16) in current file = "1003-10005"
>>
>>
>> What is the exact lookup statement in your test file?  What is the exact
>> value of the key used in that lookup?
>>
>> Test file:
>>
>> 2  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>> keys  ◄ If:
>>         Then: lv="1003-10005"
>>    3  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>         ◄ If:
>>         Then: lookup sales = sales_journal  k=lv   i=C -nx
>>    4  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>         ◄ If:         NOT sales
>>         Then:         beep;errorbox "Record Not Found";END
>>    5  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>         ◄ If:
>>         Then:         msgbox "Record Found";END
>>    6  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>
>> This works with both *clerks programs
>>
>>
>> Working file:
>>
>> This doesn't even if lv= "1003-10005"
>>
>> 445  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>          ◄ If:
>>          Then: aa="(brw=10 xkey=xs show=keep pop=show fill=desc,top)"
>> 446  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>          ◄ If:
>>          Then: ab="[JOURNAL # START DATE  TYPE  PER    FEE       CC TYPE    LAST 4]"
>> 447  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>          ◄ If:
>>          Then: ac="*1        *6            *7    *8  $*9          *14      *32"
>>
>>      
> 1.  Above you say that it doesn't work with lv="1003-1005", but below
> the browse lookup is using a key of
> field 16.  So for the case where you know it will bomb (maybe follow
> with debugger), what is the value
> of field 16 when it hits line 448?
>    
>> 448  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>> do_lk_r◄ If:
>>          Then: lookup sales = sales_journal  k=16   i=C -NXm b=(aa&ab&ac)
>> 449  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>          ◄ If:         @sk = "BRKY" or @bk = "X"
>>          Then:         CLEARB;SHOW "";pw="";END
>>
>>      
> 2.  The test "not sales" is not done before line 450, so that needs
> more.  [In other words, if not sales and if
> @bk = "s", then you would expect that depending on the success of the
> lookup, filepro could throw its standard lookup not performed error for
> trying to reference 'sales(@rn)'.]
>    
>> 450  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>          ◄ If:         @bk = "s"
>>          Then:         rn=sales(@rn);GOTO lok_sjn
>> 451  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>>          ◄ If:
>>          Then: CLEARB;END
>>
>>
>>
>>      
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>
>