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

[GCC Consulting]

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