Suppose your faced with a need to generate a report of invoices (formatted as invoices) organized numerically by invoice number, alphabetically by customer. The obvious process for this is to create a Clarion application that first reads the Customer row, then an Customer Invoice row, and finally the Customer Invoice Detail rows.
During these three interleaved processes, building local variable summary data is also being saved off. Formating of all this customer-based data for printing a specific overall invoice for the Customer is then undertaken. Thereafter your Clarion application proceeds to the next Customer row and starts the reporting process all over again.
In contrast to having to write these detailed hand-coded process-centric Clarion applications, UpAndUp creates the invoice reports for customers that for each customer record, activates a second process that obtains the related Customer Invoice information and finally accesses the Customer Invoice Detail information that results in the information necessary for the Customer Invoice report.
All of this is done in one progress window, and a single standard timing loop. The entire hierarchy tables whould be in a single table schematic that UpAndUp uses to automatically figure out both how many processes it needs and also creates the process hierarchies automatically. Once the report data is captured, output can be through the ABC alternative report targets of: HTML, XML, and PDF.
The UpAndUp described above solution to multi-table integrated report writing replaces one or another of our commonly used traditional multi-table report strategies.
The first entails creating a Clarion view that combines the involved tables. That bascially squashes the rows across all these tables in a big flat file. That the creates a new problem of making the single huge flat table of rows to somehow be seen as hierarchical. Or, you can use Clarion's use Clarion's "ReportChildFiles" template that only handles one related level per report. Not good for sure. And finally, the hand coded reporting program must processs the flattened header and detail that, in turn, have to be addressed in hand coding.
The second includes the hand-coding multiple reports can be created where the first calls the second and so on. On the plus side, this solution handles an N-level database. However, on the minus side, the overhead of a procedure call is significant as well as having to deal with the additional overhead of opening and closing report windows. All this just makes the ability to accurate resources for report runs "far less than ideal."
The UpAndUp is just not a "one trick pony." It also includes additional features, for example:
⦁A TakeRecord embed (of course)
⦁A TakeNoRecords embed called only when a parent row has no child rows
⦁A TakeStart embed that gets control before any block of related rows are processed (convenient place for printing block headers)
⦁A TakeEnd embed that gets control after a block of related rows are processed (for footers of course)
⦁Totaling
⦁Sorting,
⦁A dedicated ViewManager with all its embeds, and
⦁The ability to pass totals from on level to another for summary totaling.
Given that this multi-table report writing solution is really valuable, please proceed with the Demos, and Purchasing.