|
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
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.