Hi everybody,
I was wondering if there is a way to use a loop in a report that is called more than once throughout a procedure without getting the (FOC1851) DUPLICATE DASH REPEAT LABEL error ? One option is to copy the report multiple times with different names and another is not to use a loop , but both are foolish ...

Yes, use a variable prefix to your labels and pass that variable each time you EX or INCLUDE the fex.

T

I find it safer to use Tony's second oops, first suggestion

EX app/bvmusage_report.fex STARTDATE=20090101 , ENDDATE=&YYMD.EVAL

i do an EX and pass parms on the command line.
that way, the fex is self-contained and the labels don't need any fancy management.

This message has been edited. Last edited by: susannah,

Is this report (both parts) stored on MR, or on the reporting server? On the server I've never had a label-conflict problem induced by multiple -INCLUDEs of a single fex file (or -INCLUDE within a -repeat loop), as long as the inner and out fex have no conflicting labels.

But if your outer fex and inner fex each have a -REPEAT, and they use the same label, that would earn a FOC1851.

quote:

Originally posted by Tony A:
Yes, use a variable prefix to your labels and pass that variable each time you EX or INCLUDE the fex.

T

Please expand on that. I find that a label containing amper references, even with .EVAL, is not deemed a "match" by GOTO or the terminal jump of REPEAT. For instance:

-DEFAULTH &SFX='A'
-REPEAT :loop.&SFX FOR &I FROM 1 TO 5 ;
-TYPE *** loop &I ***
-:loop.&SFX.EVAL

Although dialog manager processes the loop code nicely, when the REPEAT's exit condition is finally reached it stops dead with:

(FOC305) SPECIFIED LABEL NOT FOUND: :loop.A

- - -

More thoughts, after looking over some client traces here.

IBI not too long ago announced a change to answer complaints that error messages did not relate to the real location in the underlying focexec. Before that change, MRE would insert the content of a called MR fex (whether invoked by EX or -INCLUDE) in situ, replacing the EX or -INCLUDE line.

But if the same fex was included in multiple places, that led to repetition of identical code inline, leading to label conflicts. My recollection is that under that scheme, as a work-around to the label conflict issue, MR would perform parameter substitution for parameters appearing on the EX command, so Tony's method could be used to overcome the conflict: By the time WFRServer saw the code, the ampers in the labels were gone, and the labels were distinct.

No more. Now (at least as of 7.6.7) the EX or -INCLUDE remains (with the fex reference reworded, app/ removed) and the adhoc fex MR send up to the server loads the referenced MR fex (and any it references, ...) by means of "EX -lines ...". That means the set of fexes operates essentially as if they were all stored on the server in the first place.

That feature's generally a good thing all around -- but I believe as a side-effect any called fex that attached a variable prefix or suffix to its labels to achive uniqueness under the old regime, will fail under the new one: The &var reference will remain as is, in the copy that Server receives; in the -GOTO (or -REPEAT) it will be resolved to the parameter value, and that resolved value will not be found as a label when GOTO (or the at-end operation of -REPEAT) scans for a matching line.

This message has been edited. Last edited by: j.gross,

Jack,

That sums it up, and confirms my recollection.

However, I would add that I have seen this behaviour change between releases and I wouldn't be surprised to see it change again ...... and again.

As you and I both know, it is better to proof your code against changes by using well formed logic - something that GUI users might not be able to do - which is why "old" hands like us use the text editer to code!

T

I've done this a number of times. The thing I never do is put the eval in. You might want to try that.