Re: ON FIRST ROW

Don't miss the point. There are numerous ways of grouping your data outside your report and I am in fully in agreement with your point about getting it all done first. However, there are still requirements for an ON FIRST ROW, (I refuse to use FIRST PAGE HEADER in that I have to repeat a complicated HEADER in PAGE HEADER). For example, you may have some grand totals required for the report which are more complex than group sum(). Totals that only summarise based on exception for example. In these cases, our technique satisfies a simple requirement in a simple way. Thanks for your reply. Neil - @storm@aztec.co.za < ANOTHER ESSEX LAD > Andy Kent (akent@cix.compulink.co.uk) wrote: : > : > We use the following technique to create the equivalent of a ON FIRST : ROW : > clause. It is extremely useful when you want to declare cursors in : > a report only once, or perhaps do some sub-totalling on all rows sent : > down to a report when group sum() won't work. : > : > foreach c_report into p_vars.* : > output to report rpt(1,p_vars.*) : > end foreach : > : > The report then looks as follows : : > : > report rpt(r_first_row, r_vars) : > : > define r_first_row smallint : > define r_vars record like vars.* : > : > order external by r_first_row, r_vars.other_group : > : > before group of r_first_row : > declare cursors... : > initialize r_sub_totals : > : > Comments please... : Yuk! Always try to get your database activity out of the way outside of : the report function, because: : (1) Joined queries are nearly always faster than nested cursors, unless : you've got the indexes wrong (for all the usual reasons that I can't be : bothered to list...) : (2) It makes your code neater and easier to follow. It's also the way : SQL-based products were intended to work. : (3) If you can get the grouping out of the way before invoking the OUTPUT : TO REPORT you save the report formatting function having to generate temp : tables. SQL could possibly have evaluated the grouping through an index, : or at least sort-merge joins, which are faster. : akent@cix.compulink.co.uk (Andy Kent) : ------------------------------------- -- Neil - @storm@aztec.co.za < ANOTHER ESSEX LAD >