>>> 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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: Jared.Still_at_radisys.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).