lookup problem

Rkreiss@verizon.net] rkreiss at verizon.net
Wed Aug 4 08:43:45 PDT 2010


Top post from phone:

Bruce,

The program starts from a batch file which brings up the dpromenu.

I have a seperate menu run from dpromenu for debugging programs.

After each change in my program, I do a syntax check anf tokenize the processing table.

As I am not at my computer currently, I can't give you my -t settings but the are set high as I have some very large processing tables which complained untill I adjusted the settings up.

I will compare the times of the prc & tok tables when I get home tonight.

Both versions are 5.6.10.  My laptop only has this version loaded.  One the other hand, my office system has 4.5 through 5.6 available.

What I have found interesting is the doing a lookup from testfile using the same code works with both clerks.

The only thing that is different is the primary file has an auto processing table that looks up to the sales file to get the currect sales journal number and uses thst to get info from a transaction file.  That lookup works.  

I think I might create a variable to hold that record nuber and use it in the routine to display the record.  Be interesting to see if this works without causing an error message.

The lookup in auto is unprotected.  Just in case the auto process was locking the record, I did add a write sales to release the record just in case.

Richard

-----Original Message-----
From: Bruce Easton <bruce at stn.com>
Sent: Wednesday, August 04, 2010 8:53 AM
To: filepro-list at lists.celestial.com
Subject: Re: lookup problem

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  -------   -   -   -   -   -   -   -   -   -   -   -   -

[The entire original message is not included]


More information about the Filepro-list mailing list