Re: RETURN within REPORT (was: Do you need a "on every row")

>From: walt@mathcs.emory.edu (Walt Hultgren {rmy}) >Subject: RETURN within REPORT (was: Do you need a "on every row") >Date: 12 Oct 1993 11:51:57 -0400 >X-Informix-List-Id: <news.4579> >The recent discussion about forcing at least one page from a report that >receives no data caused me to make another attempt at finding a general >solution to the problem. > ... >I have recently been thinking about using a method, demonstrated in the >test program below, that depends on using a RETURN statement within a >REPORT module... >I couldn't find any specific mention of *not* using RETURN inside REPORTs >in the manuals, so I just tried it and it worked, at least in I4GL 4.11.UC1 >under SunOS 4.1.3. I thought it might since we use c4gl, which implements >REPORTs as C functions. >Before I get more involved with this approach, such as deciding how to >handle GROUP clauses, I'd like to know if anyone can see any problems with >it. Does this also work in RDS? Is RETURN within REPORT just a currently >untrapped keyword that happens to work in C, or is the connection between >REPORTs and functions fundamental enough to 4GL that this is likely to >continue to work? A report *is* just a function, but it is a most peculiar function. First, and most importantly, it cannot be called correctly from within I4GL except using the START REPORT, OUTPUT TO REPORT, FINISH REPORT statments, because all functions callable from I4GL take a single integer argument, but report functions take two integer arguments -- there is no way to supply the second argument, so you get random garbage (or a core dump) if you try to do so. Second, the local variables in a report are static variables, not automatic like they are in any other function. The compiler cannot prohibit a report from being called -- the call could be in a module where the report is neither defined nor used with START REPORT etc, and therefore could be a perfectly legitimate function call. It does not validate that a function has not been used as a report (or vice versa) in a single module, because it would not give guaranteed protection. I'd be very careful about using RETURN within reports. It is not disallowed (hence, it is allowed), but the semantics of things like aggregates are not defined in the presence of RETURN statements. Also bear in mind that some reports have three phases -- there is a data accumulation phase, a sort phase, and a print phase. This 3-state behaviour can be triggered by the use of ORDER {INTERNAL} BY, or the presence of aggregates in anything other than the ON LAST ROW clause, or by the presence of GROUP PERCENT in an AFTER GROUP OF clause (look very hard at the definition of GROUP PERCENT on p5-50 in the Informix-4GL Reference Manual, Vol 1, 4.00 Version). In these reports, the sort and print phases are triggered by FINISH REPORT, and any RETURN in the body of the report will unilaterally terminate the report, probably part way through the page. Goodness only knows what happens if the report is re-used! Given the above comments, I think exploring this approach is sufficiently fraught with dangers that I wouldn't do it. However, you are at liberty to try and use it, but you'll need to take these considerations into account. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>