When do deleted report and instances get removed from the server

when do deleted reports and get removed from the server? I think there is a process that deletes daily?

I believe there is a recycling bin starting in version 4.2 . Only an administrator would have access to this. By default recycle bin is emptied (and permanently deleted) after 30 days but you can change this setting.

thanks. we are on 4.1. I still think the files get deleted. I just need them off the drive and I am wonder when the get deleted. Just trying to free up some disk space.

You can try reducing the number of instances in the history by using limits on the folders in the CMC. There are settings for the total number of instances for each schedule, and the maximum instances age in days. Be sure to communicate to the user community as they may refer to the old instances in the history.

The settings are applied over night, around 4 am I think, so you will see the results the next day. You can use the instance manager to play around with date ranges to show how many instances will be removed.

In reference to the Recycle Bin, this statement is not correct. An administrator has access to all objects in the Recycle Bin through the CMC interface. Individual users will have access to their personal recycle bin through the BI Launch Pad. They will see only the reports that they have deleted. The Recycle Bin option will not show up until they have deleted a report so it will not be visible at first. While I am discussing the Recycle Bin, it should be noted that only the actual reports are sent to the Recycle Bin, report instances do not go to the Recycle Bin, once they are deleted, they are removed and would have to be regenerated.

Since you are still on BI 4.1 and don’t have the Recycle Bin, the timing there wouldn’t come into play. When you delete a report, it’s entry is removed from the CMS database immediately. There will be an expected delay for a process to run to remove the actual file from the file repository. @ROMAN may be correct in that it runs around 4:00 am. I’m not sure of his local time or if his reference is UDT time. I have not paid much attention to when this part runs. I have observed that whenever the process runs, the files do not always get removed from the file repository. I haven’t taken the time to determine why this might be but I know that you can run the Repository Diagnostic tool with the -repair switch and it will remove any files from the file store that do not have a corresponding record in the CMS database.

As for reducing the number of report instances, there are differences in when the report instances are removed depending on the retention option that you choose.

  1. Delete excess instances when there are more than N instances of an object.
    If the number of report instances is currently equal to the limit, the oldest instance will be removed when the next instance is generated. From the CMS reference, this is immediate. When the instance file is removed from the file repository would have some processing delay.
  2. Delete instances after N days
    This option runs at some point after the date changes. I don’t know if this is based on UDT time or local time. Once a report instance is older than the number of days that are set, it will be removed. Again, this is relatively quick from the CMS reference but there would be some delay for when the file is removed from the file repository.

Note that these two options can be used together. We use both options in our non-production environments to better manage brief testing efforts.

Even with all of these options, you may still need to run the Repository Diagnostic tool to clear out files from the File Repository. You should run it with the -scanfrs and -scancms switches first to see what files it finds to correct and review those lists. I have observed that some reports will lose their link between the CMS database entry and the file path\name and the file gets removed which causes those reports to start failing. The file in the file store then needs to be replaced, either by copying the report file from another environment, or migrating that report from another environment.