Could this be a bug in FilePro? (Was--Weird output with associated field)

[Boaz Bezborodko]

GCC Consulting wrote:
>   
>> -----Original Message-----
>> From: filepro-list-
>> bounces+gccconsulting=comcast.net at lists.celestial.com [mailto:filepro-
>> list-bounces+gccconsulting=comcast.net at lists.celestial.com] On Behalf
>> Of Boaz Bezborodko
>> Sent: Wednesday, January 30, 2008 11:50 AM
>> To: filepro-list at lists.celestial.com
>> Subject: Re: Could this be a bug in FilePro? (Was--Weird output with
>> associated field)
>>
>>     
>>> when I look at the code, I am also making some assumptions, but they
>>> should be confirmed:
>>>
>>> first, note as Ken White's suggested code shows, make sure to use
>>> -nl for the lookup that tests if you've gone beyond your range
>>> of records of interest.
>>>
>>>       
>> I replaced the flag with the -nl and have the same problem, but I
>> expected this since the problem is occurring at the beginning of the
>> file.
>>
>>     
>>> Are ba and bb global (or have their expected values every time they
>>> get to where they are tested as part of the conditional lookups)?
>>>       
>> They are global and are listed in AUTO processing.
>>
>>     
>>> On both command line and in the lookups you are using letter o and
>>>       
>> not
>>     
>>> zero, right?
>>>       
>> Right.
>>
>>     
>>> You say index "o" is built on date field "20".  Is that also the same
>>> edit and does the index go across ten bytes of that date field?
>>>       
>> It is the same edit, though they are all (8,mdy/). In my field it is
>> 'ai' that is incorrectly set to 10 bytes. But this shouldn't cause the
>> problem as it is at the end of the processing. Even with fixing this
>> the
>> error occurs. In stepping through with debug I've confirmed that the
>> first record chosen by the "LOOKUP -" is the record with which I have
>> the problem.
>>
>>     
>>> After checking all this, are you getting the expected # of
>>> records selected?
>>>       
>> No. Whenever I use this method I'm always off by the number of
>> populated
>> associated fields after the first one. So FilePro does a "SELECT" on
>> the
>> record as it should, but it is only adding the first associated field,
>> and not any subsequent ones, *in the first indexed record only*. If the
>> same record was to appear anywhere but first in the indexed order then
>> all the associated fields are added as records. And if a different
>> record with multiple associated fields populated is first in the
>> selection order then it will also have only the first associated field
>> selected as records for the output.
>>
>>     
>>> If you think selecting the right records, but still are not getting
>>> the expected output, then post the output processing as well.
>>>
>>>       
>> 1 ------- - - - - - - - - - - - - - - - -
>> ◄ If: ◄
>> Then: lookup glap k=A1 i=a -nx ◄
>> 2 ------- - - - - - - - - - - - - - - - -
>> ◄ If: not glap ◄
>> Then: beep;show "@ACCOUNT NUMBER NOT FOUND"&1 ◄
>> 3 ------- - - - - - - - - - - - - - - - -
>> ◄ If: ◄
>> Then: ab(36,*)=glap(2) ; ac(8,*)=glap(7) ; ad(48,*)=27 ; ◄
>> 4 ------- - - - - - - - - - - - - - - - -
>> ◄ If: 32="PAYROLL" ◄
>> Then: ae(1,*)="P" ◄
>> 5 ------- - - - - - - - - - - - - - - - -
>> ◄ If: ◄
>> Then: END ◄
>> 6 ------- - - - - - - - - - - - - - - - -
>>
>> Since there is no PRINT statement then all records that are selected
>> should appear on the report. But the error is occurring before this
>> part
>> of the process. If I used the indexing method then I get fewer records
>> selected then if I go through the whole file.
>>
>> Boaz
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>     
>
> Have you tried a selection set using  20 eqf @td and -j on the command line?
>
> This should select your records rapidly and avoid your -v selection processing but give you the selection speed you're looking for.  Or at least 
> See if all of your records are being selected.
>
>
> Richard Kreiss
> GCC Consulting
> rkreiss at gccconsulting.net
>   
-J is an IUA command, not a report output command.

Boaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20080130/4d2a3733/attachment.html