Fwd: Re: Reporting - Casting about for ideas

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