| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Reporting - Casting about for ideas
We don't use the Oracle Reports Server, but I seem to remember it offers
report caching. I did a quick search on Metalink and found this:
Note:118223.1
TOLERANCE PARAMETER
3. Creating a backup using the Reports Server One of the parameters of the
Reports Server, is the Tolerance parameter. This parameter specifies a
certain period in which a report which is ran again will use the cached
output iso actually running the report again. Just add the tolerance
parameter to the run report command, run the report to file, run the report
again, but now to the printer. When you run the report to the printer, the
cached output will be used. So if the print fails, you still have the
backup of the report printed to a file. And if the tolerance period has not
been expired, you even have an extra copy in the cache and can issue the
print command again.
4. Example In this example we will first print a report to file and then to the printer. To do this the Reports Command Line Interface is used, but the same can be done from the other run options (see chapter 2). Step 1, print the report to file: RWCLI60 <report name> <connectstring> SERVER=<repserver> DESTYPE=file DESNAME=<filename> TOLERANCE=<#min> eg. RWCLI60 emp scott/tiger_at_orcl SERVER=repsrv6i
DESTYPE=file DESNAME=emp TOLERANCE=5 Step 2, print the report to the printer using the cached output from step 1: RWCLI60 <report name> <connectstring> SERVER=<repserver> DESTYPE=printer DESNAME=<printername> TOLERANCE=<#min> eg. RWCLI60 emp scott/tiger_at_orcl SERVER=repsrv6i DESTYPE=printerDESNAME=las4d TOLERANCE=5
> -----Original Message-----
> From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com]
> Sent: Thursday, October 31, 2002 3:49 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Reporting - Casting about for ideas
>
>
> 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:
> 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).
>
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: David.Schmoldt_at_gazettecommunications.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).Received on Thu Oct 31 2002 - 18:28:39 CST
 |
 |