Re: Re: Reporting - Casting about for ideas

Hello Jared

BMC has a product that allow you to send reports to disk and then use web access to browse the reports. I am sure that there are other tools that does the same.

(disclaimer - this from a talk I had with one of our guys, no first hand knowledge).

Yechiel Adar
Mehish
----- Original Message -----
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Sent: Friday, November 01, 2002 8:43 AM

>
>
> On Thursday 31 October 2002 14:45, Fink, Dan wrote:
> > Jared,
> > To state the obvious...'Throw away solutions some how never get
> > thrown away'.
>
> Yeah, well, I had thought of this. I'm stuck with this strategy however.
>
> > Okay, now on to the real task at hand. A couple of ideas
> > Dump the reports out to html format (sql*plus can do this) and the
> > users can hit an url for the history. Using a little code to insure that
> > the front page shows the current report, with a secondary page with
links
> > to other pages/reports.
> > Dump the compiled data to flat files on the network and let another
> > app (access/excel) get the data, format, graph, display it, etc.
> > Oh, (in deference), write a series of perl scripts...
>
> Sqlplus won't work. This is SAP. If you're not familiar with SAP,
sqlplus
> is not an adequate reporting tool. Though all SAP data is stored in
tables
> in the database, there are some that are stored as either 'CLUSTER' or
> 'POOL' tables, SAP terminology, not Oracle's. The data is not readable
> from sqlplus.
>
> Whatever the solution, I want to avoid coding an infrastructure. I'm
looking
> for a solution that is fairly simple to build. It may or may not get
thrown
> out later, but there will eventually be a DW to supplant it.
>
> Thanks,
>
> Jared
>
> > Dan Fink
> >
> > -----Original Message-----
> > Sent: Thursday, October 31, 2002 2:49 PM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > 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
>
> -------------------------------------------------------
> --
> 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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Yechiel Adar
  INET: adar76_at_inter.net.il

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).