-v processing
Bruce Easton
bruce at stn.com
Wed Jun 10 11:06:36 PDT 2009
Dennis Malen wrote Tuesday, June 09, 2009 11:25 PM:
>
> The following now works:
>
> 14 -------- - - - - - - -
> nextsel~ If: ww="" and 3 lt dt
> Then: lookup - k=dt i=B -ng
> 15 ------- - - - - - - - - - - - - -
> ~ If: ww="" 'and 3 lt dt
> Then: msgbox "See1:"<cn; goto chckcn
> 16 ------- - - - - - - - - - - - - -
> chckcn2~ If: 3 ge dt and 3 le dy
> Then: select
>
> 50 ------- - - - - - - -
> chckcn ~ If:
> Then: lookup clx k=8 i=A -nx
> 51 ------- - - - - - - -
> ~ If:
> Then: msgbox "See2:"<clx(38)<cn
> 52 ------- - - - - - - -
> ~ If: clx(38) ne cn
> Then: msgbox "See3:"<clx(38)<cn;end
> 53 ------- - - - - - - -
> ~ If:
> Then: ww(1,*,g)="y";goto chckcn2
>
> Comments:
>
> 1. I don't know why I need "and 3 lt dt" on line 14. That is
> the only way it works.
>
> 2. Also the menu line for the report does not have to
> identify "In". Works the same with or without it.
>
> 3. The concept of what was done above is that we did not
> allow the program to go to the "select" line until the record
> was also equal to the value of cn.
>
> 4. We overlooked the fact that line 15 should not have
> included "and 3 lt dt".
>
> 5. I also needed a conditional subroutine that checked for
> the value of cn before the first record was allowed to go to
> line 16. After we found the first record that possessed the
> value of cn, we would then populate the value of ww (line 53)
> so that the program would not revisit this subroutine.
>
> Dennis Malen
> 516.479.5912
>
Dennis - for your comment #2 above, I think you might
have just been lucky with how your key field (for your
lookup dash lookup) coincides with the file's record
numbers if you see no difference (or maybe you're not
lucky, but things just appear good).
The lookup dash technique as posted by Nancy at:
http://www.vss3.com/tips/tip_9.htm
(as noted by Walter Vaughn back on Friday),
does specify that the index is to be used on the
command line. And in doing so, along with the
appropriate lookup dash(es) used in the program,
allow the report request to work in a very
specific way. Just as important as moving the
record pointer to a desired spot in the file
(from its current location) is doing so in a way
that will not bypass records that should be
considered.
Consider the following processing:
1 ------- - - - - - - - - - -
If:
Then: 'find all recs with fld 1 ge '242'
2 ------- - - - - - - - - -
If:
Then: show "@Reading rec#"<@rn
3 ------- - - - - - - - - -
If:
Then: gg(6,.0,g)="242"
4 ------- - - - - - - - - -
If: 1 lt gg
Then: lookup - k=gg i=A -ng
5 ------- - - - - - - - - -
If:
Then: select; show "@Value for Rec#"<@rn<"="<1
6 ------- - - - - - - - - -
If:
Then: end
Notice the first show statement. This shows the order
of records read/considered prior to the neato
fancy-nancy-like lookup being executed.
If I run this against the test file below
(see ===test file===), with a command line as such:
/appl/fp/dreport test5 -f test -v testsel -u -y nnn -a
(no index specified and notice that the last
record in the file is lower than what we are looking for)
then we get:
Reading record 1
Value for Rec# 1 = 642
Reading record 2
Value for Rec# 6 = 410
Reading record 7
Value for Rec# 6 = 410
Reading record 6
Value for Rec# 6 = 410
Reading record 6
Value for Rec# 6 = 410 and then we are caught
in a ppp (perpetual processing problem)
so here we found only two of the three values,
but then got into an infinite loop (output phase
still sitting there saying - 'hey - give me somethin'!'
if I change the last data record to be say 242
instead of 20 (see ===test file=== below),
then running again, I get:
Reading record 1
Value for Rec# 1 = 642
Reading record 2
Value for Rec# 8 = 242
and the program does terminate normally, but
what happened to records with values 410 and 500??
Well looks like the combo of moving the pointer
around and filepro continuing to try to process
in record-number order cause those records to
never be read - so no matter what kinds of other
tests I put in processing, I'd never select them.
So I'm thinking that enough of your file's
key data is coinciding with their record number
order to give you the impression that it is
working OK. And maybe in this one instance, it
is selecting all the records you think it should,
but if you deleted some records and added new ones
with your key field values varying across your
selection threshold, then I think you'll find
yourself in one of the two scenarios I described
above.
Using the technique as it should be, with the
index on the command line:
/appl/fp/dreport test5 -f test -ia -v testsel -u -y nnn -a
the results are what they should be to grab all values
ge 242:
Reading record 2
Value for Rec# 8 = 242
Reading record 6
Value for Rec# 6 = 410
Reading record 4
Value for Rec# 4 = 500
Reading record 1
Value for Rec# 1 = 642
with normal exit.
===test file==='s data:
Rec# Field 1 Value
--------------------------------
1 642
2 2
3 16
4 500
5 27
6 410
7 29
8 20 (then changed to 242)
***** END OF FILE *****
***ALSO, Dennis, you mention in a subsequent post that,
"We are in the process of modifying many other formats to take advantage of
-v now that we can implement auto processing."
For those reports, if the typical subset of data needed is
significantly smaller than the entire file, and can very well
not be at the end of the file (in the look-dash index order),
then you should be applying the look - -i[index] -nl
lookup as well to skip quickly to the end of the file
(also shown in Nancy's tip).
Bruce
Bruce Easton
STN, Inc.
More information about the Filepro-list
mailing list