Could this be a bug in FilePro? (Was--Weird output withassociatedfield)

[Bruce Easton]

Boaz Bezborodko wrote Tuesday, January 29, 2008 11:03 PM:
>
> I just modified the -bg to -ng and I still have the same problem.
>
> Boaz
>
> ken white wrote:
> > I just tried it with an additional field in my sort criteria also
> > without issue.
> >
> > change your -bg  to -ng on the lookup - in the start,  and -nl on the
> > lookup - on  when the date is > then your end date.
> >
> > ----- Original Message ----- From: "Boaz Bezborodko" <boaz at mirrotek.com>
> > To: "ken white" <kenwhite at verizon.net>
> > Sent: Tuesday, January 29, 2008 10:06 PM
> > Subject: Re: Could this be a bug in FilePro? (Was--Weird output with
> > associatedfield)
> >
> >
> >> aa and ag are just additional (but optional) selection criteria.
> >>
> >> But I don't see how your code is operationally any different from my
> >> code especially when it comes to the beginning of the indexed set to
> >> be chosen. In my case I select the record I want to see, but only the
> >> first associated field is put on the report.  If I understand the way
> >> FP is supposed to work, all associated fields are supposed to be in
> >> the selection set when the record is selected, not just the first one.
> >>
> >> (I will have to change or XLATE ai to (8,mdy/) as that is the format
> >> for O, but it would only be an issue in ending the selection process,
> >> not in the beginning of it.)
> >>
> >> Boaz
> >>
> >> ken white wrote:
> >>> Boaz,
> >>>
> >>> Rewrite your sort selection table to be close to the following:
> >>>
> >>> :ba="":gosub getsel:
> >>> :20 lt ba:lookup - k=ba i=O -ng:
> >>> :20 gt bb:gosub fini:
> >>> :20 lt ba or 20 gt bb:end     'safety:
> >>> :ag ne "" and ag ne 17:end:
> >>> :MID(30,"1","13") eq "Keyoffs check":end:
> >>> ::'any other criteria which could end the selection criteria is
> >>> inserted here:
> >>> :aa="" and 19 ne "AD":select:
> >>> ::end:
> >>> ::':
> >>> fini::'get the last record in the index:
> >>> :ai ne "":return   'already ran once, incase of multiple values in
> >>> the index.:
> >>> ::ai(10,mdyy/,g)="12/31/2050":
> >>> :: lookup - k=ai i=O -nl:
> >>> ::return:
> >>> ::':
> >>> getsel::'all selection questions are located in this routine.:
> >>> ::input popup ba "Enter Start Date > ":
> >>> :@sk="BRKY":exit:
> >>> :ba="":goto getsel:
> >>> ::input popup bb "Enter End Date > ":
> >>> :@sk="BRKY":exit:
> >>> :bb lt ba:goto getsel:
> >>> ::return:
> >>> ::':
> >>>
> >>> The point being that the first couple of lines evaluate the position
> >>> of the date in index O.  After the dates are validated all other
> >>> selection criteria is then validated and the record is selected or
> >>> not.  I do not know from your sample what is contained in the fields
> >>> AA or AG and where they are set.
> >>>
> >>> Another issue you need to pay attention to is the -ng and -nl on the
> >>> lookup - lines.   You do not want filepro to return an error when
> >>> the begin date or end date does not exist.   The -nl in the fini
> >>> sub-routine causes filepro to find the last record in the date index.
> >>>
> >>> I am also assuming that index O is built on a 10, mdyy/ data field
> >>> and not 10,yymd or any other date variant, and that it is actually a
> >>> date.
> >>>

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.

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

On both command line and in the lookups you are using letter o and not
zero, 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?

After checking all this, are you getting the expected # of
records selected?

If you think selecting the right records, but still are not getting
the expected output, then post the output processing as well.

Also, please post the exact script line that starts the report.

Bruce

Bruce Easton
STN, Inc.