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

Jonathan Leffler (johnl@informix.com) wrote: : >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. : 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. : 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> I would strongly suggest _NOT_ using this approach. I do not remember the circumstances, but I had inadvertently put a return in a report program one time and it caused a major problem, one which was very difficult to debug! Ryan McFall "I'm just a poor Graduate Student" mcfallry@cps.msu.edu