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: > [EMAIL PROTECTED] 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: [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).
