Re: Any report writer suggestions?

[Richard Schoen <richard@xxxxxxxxxxxxxxxxx>]

FWIW: there are a couple of CL commands in my QShell on i Utilities for doing SQL data extraction and prep. 

QSHQRYTMP - Takes in an SQL statement on the command line or embedded in a program and produces and outfile of results that can be run through Jasper Reports or any other report writer. 

QSHQRYSRC - Takes in an SQL statement from a source member or an IFS file and produces an outfile of results that can be run through Jasper Reports or any other report writer.

QShell on i
https://github.com/richardschoen/qshoni

Regards,
Richard Schoen
Web: http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
 
----------------------------------------------------------------------

message: 1
date: Fri, 26 Jul 2024 15:40:18 -0400
from: Rob Berendt <robertowenberendt@xxxxxxxxx>
subject: Re: Any report writer suggestions?

A vast number of the report writers have one often doing this within their tool with data models, etc so I recommend just biting the bullet and doing as he said; create the views, etc.  Put the performance on the back end database.

On Fri, Jul 26, 2024 at 12:02?PM Bill Langston <langston@xxxxxxxx> wrote:

> Troy,
>
> As you said, there are many methods and tools/apps, open source and 
> licensed, and I work for a vendor so you may discount this advice, but 
> in my experience, the main report writing hurdle for business users is 
> learning which of the dozens (hundreds?) of tables in your application 
> database have the data they want.
>
> If you haven't already done so, consider spending some time now 
> studying your DB2 on i database, note the tables that are most often 
> joined in your existing report programs, and collect some queries from 
> your most skillful clients. You will probably discover that the vast 
> majority of the reports clients want query a handful of your application's tables.
> Create some SQL Views that join those frequently queried tables 
> correctly so your clients don't need to figure that out. Your SQL 
> Views can also format dates and other values that might confuse your 
> clients, provide meaningful column names, etc. Once you've done this, 
> any tool you choose will be easier for users to learn and your staff to support.
>
> Good luck.
>
> Bill Langston
> New Generation Software, Inc.
> www.ngsi.com