We have about a dozen Reportcaster jobs that check every 10 minutes for changes in a database, such as a receiving event in inventory, and send an email to a salesperson to let them know the inventory is received.

I set this all up using SQL views on the database side, and added a post-process to do an insert into a log table once the reportcaster job completes. I found this process simpler to understand and administrate than Alerts for a one-database system like ours.

Now, our reportcaster log files get so full so quickly (since our jobs run every few minutes all day, every day) that I have to clear them out once every few weeks to keep reportcaster running efficiently. We are on the default Focus repository. More users want to add more of these few-minute processes, so the problem is just getting worse.

What can I do to fix this as easily as possible? Would converting to Alerts give us any advantage in functionality or fill up the logs less, or can we migrate from Focus repository onto our DB2 UDB/iSeries database instead and will that make Reportcaster run longer without having to clear the logs?

Thanks for your help!

We have a couple of jobs that run every 2 minutes (don't ask!!) and we still have to manage/clean the log files (also with a separate RC job) and our database is DB2/UDB. So converting your repository isn't goin to solve that problem. Converting to alerts would probably get you much further down the road. In the near future, here are a couple of tips:

1. Make sure that you don't have any -SET &ECHO=ALL; in your code. All of your code would be written to the log files with every run and fill it up much faster.

2. Control useage of any other Dialogue Manager commands that would output to the screen such as -TYPE

3. Where possible, make use of the &&KILL_RPC variable in pre-processor steps to prevent additional writes to the logs when it's not necessary(i.e. "alert" condition is not met)

Jason

Found this solution on focalpoint
-* Problem: How to automatically delete rows from the server log and statistics table?
-*Solution: It may be useful for a server to automate deleting rows from the server log and statistics tables. For example, you can delete all rows more than a week old on a daily basis.
-*1. Create a stored procedure with the following lines:

-SET &DDATE=AYMD(&YYMD,-7,'I8');
-SET &DDATE = EDIT (&DDATE,'9999/99/99') ;
EX \\ibiserver\ibi\srv766\home\catalog\ETLDELLS DDATE=&DDATE, DTIME=00:00:00, SUSTART=Y, ETLSTART=Y

-*2. Create a new process flow.
-*3. Drag the procedure into the flow and connect it to the Start object.
-*4. Drag a Schedule icon into the workspace.
-*5. Double-click the Schedule icon and set a schedule for running the flow.
-*6. Save the flow.


We run this once a week via ETL.

You can change the setting for purging log files in
ReportCaster Server Configuration\ General Tab\ Log Purge Period option.

Thank you for all the advice!

quote:

Converting to alerts would probably get you much further down the road.

What advantages would we see from converting these processes over to the alert technology? It's been a while, and we don't have any actual alerts set up any more, but I think they wrote to the log files as well, has that changed?

A question for all you BI veterans, how are you sending notifications to your users based on alert-type information? I get the feeling that we must be doing something wrong as our server requires monthly maintenance just for the dozen or so 'instant alert' 10-minute processes. I've heard of companies running a LOT of these type of things, do their servers require this same maintenance?

Our server guru suggested that we spend some money on hardware, more ram and processor, to eliminate the very bad lag that we get after about two weeks of logs build up.

Does anyone have any experience with Reportcaster on windows before and after a hardware upgrade?