Re: Reporting - Casting about for ideas

Stephane,

Yes, you have hit upon the crux of the problem. Generating reports is easy, but managing the output is hard. I was hoping to find that someone here had faced the same or similar problem at some time. Doesn't look like it though.

The idea for using a table with a BFILE sounds like it might be a good start though. Manipulating the metadata for the report output would be much easier in a table than trying to do so by simply walking filesystem directory tree or working with a flat file.

Thanks,

Jared

On Friday 01 November 2002 00:43, Stephane Faroult wrote:
> Jared.Still_at_radisys.com wrote:
> > Dear List,
> >
> > First, a little background. A coworker and I have been charged with
> > developing and implementing a 'short term' 'Reporting Solution'.
> >
> > Glossary:
> >
> > short term: low cast, fast to implement, throw it away late next year
> >
> > Reporting Solution: Some method to make it easy for users to
> > see oft run reports without re-running them on the production SAP
> > ( and other apps also ) systems.
> >
> > The goal of the 'Reporting Solution' is perceived performance.
> > Only 1 or 2 of these reports have any detrimental performance
> > impact on the servers. The goal is to allow users to view current
> > and historic reports ( up to 90 days ) without being required to
> > wait on reports to run on the application/database servers.
> >
> > This is partly political, partly user friendly.
> >
> > The political part is that we want to do *something* for users so
> > that it looks like we're taking their requirements to heart, even
> > though we don't have the resources to do much right now.
> >
> > The user friendly part is that we want to do *something* for users so
> > that we can make their jobs a little easier, even though we don't
> > have the resources to do much right now.
> >
> > One idea we have is to have an ABAPer ( SAP programmer ) setup
> > the most requested reports to run in batch mode with a specified range
> > of dates and whatever parameters are needed.
> >
> > This would be done periodically, the report output put on a network
> > filer or database or something accessible via browser ( no shared
> > drive type solution, access is to iffy ), and a web page that would allow
> > simple navigation to reports by Category/Date.
> >
> > Click on the report, view your data.
> >
> > One thing that this is *not*, is a data warehouse and/or data marts.
> >
> > This is to be a low cost solution. Some software OK, a server is Ok
> > if necessary. The key is fairly easy and quick implementation.
> >
> > I'm open to any and all ideas you may have for this, experiences doing
> > similar projects, etc. If it uses Oracle software, that's cool, if not,
> > that's
> > cool too. Oracle is involved in any solution: at the very least, that's
> > where
> > all our source data is stored.
> >
> > Thanks for reading this long winded message.
> >
> > Jared
>
> Jared,
>
> I like the idea of putting the reports on the intranet much. I have
> done something similar some years ago with e-mails sent automatically to
> give job status. It's easy to administer. The main problem I see is the
> _identification_ of reports; if you can define a kind of 'primary key'
> for reports (dates - criteria (XMLized perhaps if there can be a varying
> number of criteria) you can probably store a pointer (BFILE) to all
> available reports in some table, fill it with batch reports and even -
> there always be somebody wanting that non-standard report - run reports
> on-demand and make them available to the wide world.
>
> HTH,
>
> Stephane Faroult
> Oriole Software

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jared Still
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).