We are using BOXIR2 with SP1 and SP2. Recently we have got a lot of scheduled objects and we want to reduce them to the needed ones only.
In doing so, I have made the changes in SETTINGS in CMC i.e.
SETTINGS>Limit>Delete excess instances when there are more than N instances of an object =1
Similar change has been made in the specific root folder where the reports are kept. I have restarted all the services and CMS but all the instance are still there. Aren’t the exesive instances supposed to be deleted. Whats the other way to delete these instances. We are rolling out so we donot need these current instances. At the same time I cannot use INSTANCE MANAGER as there are around 2 Million instances and its not feasible to delete the objects by selecting 100 objects everytime using instance manager.
can you please experiment with the instances of one particular document.
can you schedule it again so that it creates a new instance
From memory, I think the rules about instance limits only apply when the next instance is created ?
This thread is quite old but still very relevant. I, too, am attempting to instill some order to the chaos of excessive instances. I want to set a general rule of no more than 5, 10, or 20 instances depending upon Group assignment.
Almost all are Crystal Reports.
I set global limits in the CMC under the Settings tab.
I ran over 3000 report instances. Many were multiple instances of the same reports, but overall there were at least 1000 unique reports.
Where I expected to see the limits honored, I still found many more. For one user alone, I found 155 excess instances in 4 reports. Of them, 2 reports had no recurring instances and accounted for over 100 of the instances but the other 2 did have them and did run but still had nearly 55 excess between them.
What else must I do? I have 45 users, each of which average 20+ reports. I am miserable at the prospect of manually reviewing and weeding out all of them.
Instance limit restriction picks up and you will notice the instance limit only after the report is ran on the scheduler. In other words this restriction is only applied after the report ran on the scheduler.
I understand the limits will not automatically apply without a nudge by the scheduler but what would cause the limit to be ignored when a new instance is generated by it?
I have several examples of reports with histories going back over a year. I applied a global limit of 28 days (through CMC Settings > Limits) with the expectation that numerous histories would shrink dramatically as the scheduled instances began to run. It has been several days now, a good number of such reports have run, and still the histories are enormous. I can see no evidence that any instance was deleted.
I checked the report objects to ensure there were no specific limits that would override the global settings and found that was not the case.
I am looking at over 30,000 excess instances spread very unevenly across nearly 6,000 report objects (one offender has over 4,000 instances on its own). Trying to manually reduce the clutter will take days to complete.
I’ve never tried this option of deleting instances after certain days. My wild guess is this option might only be applicable for certain users/groups specified there and the actual instance might never get deleted?
I created a group and populated it with the bulk of my user base (excluding only Administrator type users) and applied the 28 day rule to it:
Name: "Rpt-28days"
Full Name: ""
Object: "Group"
Description: "Members of this group may retain instances of reports for up to 4 weeks."
Maximum Days: "28"
I did not check the box above that reads “Delete excess instances when there are more than N instances of an object” because I was not looking to limit to a specific number. I could check the box and leave it at the default of 100 - which aught to be enough to handle 28 days worth of almost all reports - if that check box is required to make the process work. But if it is, will it delete more instances than are required to maintain the 100 count if the date criteria calls for them to be deleted? What do you think?
I think I have hit upon a sad and troubling truth.
If the limits are set before the excess instances exist then those limits will apply. If, on the other hand, the limits are set after the excess instances exist then the limits are ignored.
I have experimented with two folders to prove the point. In one, I left the excess instances alone; but I deleted the excess from the other. The result was that the objects of the first folder continued to increase instances without regard to the limit, but the objects of the second reached the limit and did not exceed it.
I consider this to be a severe flaw in the implementation of limits. I believe Business Objects needs to review and revise the process to ensure limits are enforced regardless of the state of the objects (number of retained instances) before the limit was configured. I agree the limit should be evaluated and imposed when a new instance is generated - requiring a system-wide search and destroy process upon definition of a limit is impractical and unwarranted. I disagree that the limit should be disregarded if there are already too many instances - the process should automatically delete as many instances as necessary to conform to the limit.
I don’t think what you just stated is true, as I’ve seen that it deletes instances in either case. One caveat being, if the # instances is too large than it might take some time to delete all those excess instances or might be insufficient memory.
If the CMS must be idle before the drops are performed then it will be a very long time before I see results. My users are spread across the North American continent and schedule reports to run overnight per their time zone. I am lucky to see more than 30 minutes between transmission of report results (I know this because of my use of hMailServer as a store and forward E-Mail proxy - see What happens to SMTP delivery when Internet link goes down?).
In light of your explanation, it behooves me to spend the time manually weeding out the excess to start the process and rely upon the system to maintain it from then on.
Thanks for the help and the informative explanation.
Marc
Well dont want to comment on the INSTANCE MANAGER being robust but definitely I have not seen a dumb application like INSTANCE MANAGER!
Now I have around 200,000 instances in repsitory! and I can delete only 100 instances at a time
I Even tried changing the preferences to 500 items per page…but it seems loading 500 items is the most tedious job for INFOVIEW and on top of that when you select all 500 instances and select delete, You will never be able to click on OK button Its really sick man!!!
Well I cannot use any 3rd Party tools… So if you could please give a small hint on the SDK side, I will be happy to try it out in my environment
This will only limit future instance generation.
If you had wanted to limit the generation, of all these isnatnces, you should have had it checked after installation.
(BOB member since 2005-05-23)
(BOB member since 2003-04-15)
(BOB member since 2006-08-01)
(BOB member since 2007-03-23)
but definitely I have not seen a dumb application like INSTANCE MANAGER!
and on top of that when you select all 500 instances and select delete, You will never be able to click on OK button 
Its really sick man!!!
(BOB member since 2005-01-06)