Jared - there was a very similar project done here a few years back - and yes it's still running even though the DW is starting to breathe ;-)
they implemented the intranet solution. reports go to text files on an NT box, a DOS script picks them up, runs them thru a text-to-pdf on the cheap tool, and places them in a directory structure by date. an IIS server serves them up. i could get you the specifics on that text to PDF converter if you wish. the rest is all custom scripting - and didn't take that long i'm told. i sit right next to the guy who built it. done before my time or it'd likely be apache & perl on solaris ;-) > -----Original Message----- > From: Jared Still [SMTP:[EMAIL PROTECTED]] > Sent: Friday, November 01, 2002 12:43 AM > To: Multiple recipients of list ORACLE-L > Subject: 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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: STEVE OLLIG INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
