Why Up & Up
If your databases always consist of one giant flat file, you can stop reading, because you have no need for Up & Up.
If, on the other hand, your databases are structured into related tables, in other words you normally deal with relational databases, then you really owe it to yourself to read this whole page.
Summary and Rationale
-
A little problem
Consider a simple database consisting of a table of customers, a table of invoices related to customers, and a table of invoice items related to invoices. Pretty tame stuff as relational databases go.
Suppose you would like to generate a report of invoices (formatted as invoices) organized numerically by invoice number, alphabetically by customer. As you probably know full well, the standard ABC report can't do a three-level report such as this.
The standard Clarion report is based on the concept of a process, which sequentially reads and reports the rows of a single table. The ABC process class uses a timer-based algorithm, fine-tuned for years, to keep a process from dominating the CPU while spinning through its table.
Real-world databases don't consist of single tables, so the single-table process concept creates a conundrum. How do you process invoices? (Or any other structure that requires two or more tables) Virtually every database design has invoice headers in one table and the details in a related table.
-
Some Solutions
The Clarion manuals offer two solutions:
-
Create a view that combines the tables
- Which basically squashes the relational DB into a flat file
- Which then creates the new problem of making a single table hierarchical
-
(Or) Use the "ReportChildFiles" template
- Which handles exactly one related level per report
- And which is designed for reporting, not simple processing
- And, both the header and detail recrds are passed to a single embed, leaving you to figure out the coding.
A third possibility is not mentioned because it creates too many problems:
- Create multiple reports
- Have the first report call a second report (which may call another report, etc.)
- On the plus side, this solution handles an N-level database
-
On the minus side:
- The procedure call overhead is wicked
- The opening and closing of report windows is intolerable
- It Makes a total mess of the timer-based scheduling algorithm
-
Create a view that combines the tables
- A workaround is not a solution
The ReportChildFiles template is a workaround designed to cope with a two-level invoice structure as a special case. The second level in this workaround has nowhere near the flexibility or features available for the first level.
A report of three levels or more requires using the first option, another workaround. Convert all three levels into one gigantic flat file which then has to be converted back to a hierarchy inside the report. This also limits what can be done with any but the root table.
-
A real solution
Suppose you had a reporting tool that let you create:
-
A report of customers, where for each customer record, the report activates
a second process
- The second process reports related invoices (using its own dedicated embed points)
-
And, suppose the invoice process automatically activates a third process
- The third process reports the items of each invoice it reads (with dedicated embed points for items).
- Suppose the tool supported N levels, where N is however many levels exist in your database
- And suppose all of this was done in one procedure, with one progress window, and a single standard timing loop, and required NO add-on extension templates.
-
A report of customers, where for each customer record, the report activates
a second process
-
Why stop there?
While we are in a wishing mood, why not go for broke?
- The entire hierarchy tables whould be in a single table schematic
- The tool should figure out how many processes it needs and create the process hierarchy automatically
-
For every process provide:
- 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 records are processed (convenient place for printing block headers)
- A TakeEnd embed that gets control after a block of related records are processed (for footers of course)
-
A complete feature set
- Totaling
- Sorting
- A dedicated ViewManager with all its embeds
-
Why stop there?
And of course, there should be provision for passing totals from level to level for summary totaling.
And, what the heck? Why not have it also support everything the standard report does, including all add-ons to the Clarion report, in particular the ABC alternative report targets: HTML, XML, PDF, etc.?
You just read a brief outline of Up & Up
Here is a briefer summary: ABC reporting on steroids.
Bottom Line
So what the heck does a power tool like this cost? Must cost a small fortune, right?
Actually, it costs about the same as paying one average programmer for one day.
What in the world are you waiting for?