Re: Next assignment - Reports

[Nathan Andelin <nandelin@xxxxxxxxxxxx>]

Reporting is a big topic.

On one extreme, savvy business analysts constantly come up with new ways 
to mine data, and they want sophisticated tools to assist.  If they 
don't like the way the data is stored in the database, they download it 
to their PC and transform it to the way they want, using Microsoft 
Access or Visual Foxpro or something along those lines.

On the other extreme, production reports run on schedule, are stored in 
a catalog, and rarely viewed except conditionally, and archived to 
optical media.

In the middle, an operator may prefer to select a report from a menu, 
fill in a prompt, run it to answer a question, but normally lacks the 
knowledge about table relationships and tooling that a data miner needs.

It seems that WYSIWYG designers, coupled with Query designers,  coupled 
with runtime engines are what data miners prefers, while the guy 
responsible for running scheduled reports in a production setting 
prefers runtime efficiency.

Where does the RPG programmer fit in?  He'd traditionally layout a print 
file with labels and output fields, then write a program to read data 
files, write to the print file, then use the WRKSPLF command to view and 
work with the output.

It seems to me that BIRT and Jasper Reports are tools that might appeal 
to the power user (data miner), but I'm not sure how an interface with 
RPG would help?

Nathan.




On Tue, Apr 22, 2008 at  8:08 AM, Pete Helgren wrote:

> Your post seemed to be more about execution rather than design so I 
> didn't wade into the design side but the designer side has always been 
> easy on one hand (the drag and drop metaphor) vs very hard 
> (understanding the relationships between the data available for the 
> report).  The first part, I think has been solved.  iReport and BIRT 
> along with Crystal Reports and tools from Sequel all have drag and 
> drop functionality making the actually formatting of the report quite 
> easy.  The difficulty has always been in making sure that the data 
> presented in the report relate correctly (the joins between tables are 
> correct).  This is the hardest part of a report designer and why most 
> report writing tools aren't end user tools.  Usually you buy a 
> designer package and a runtime package and you would never put the 
> designer tool in the hands of an end user because they would rarely 
> understand the nuances of how the tables relate.
>
> When I worked for NCS I was the product manager for developing a 
> report writing tool that "end users" could use.  It became an almost 
> impossible task when all the requirements were pulled together (this 
> was back in 1992 when GUI's were just getting to the point of 
> viability).  We were able to solve the "join" problems by building a 
> data dictionary that determined the proper join relationships in the 
> background as data elements were chosen but things like totals, 
> subtotals, counts, averages and the like were difficult.  Subreports 
> were out of the question given the technology available.  Eventually, 
> NCS decided to license a third party tool (a horrible thing that ran 
> in Windows 3.1) and, more recently, just told customers to talk to 
> Sequel and got a referral fee.  Bottom line: Report designers are a 
> lot harder than report runtimes.
>
> I'll look into being able to execute BIRT reports as well as Jasper 
> with this open source project.  It shouldn't be all that difficult. 
> The real challenge is providing a report designer.  I hope to solve 
> that using some "widgets" that handle the complexity in the 
> background.  They can also be used in HTML (Web 2.0) designs.
>
> I plan to generally post the availability here at in Midrange of the 
> 0.4 release today sometime.
>
> Pete