Skip to Content
0
Former Member
Jan 29, 2009 at 03:05 PM

The object with id number 'nnnnn' cannot be deleted, modified or scheduled

24 Views

I am getting this exception in the following scenario, and I'm not sure why, or what is the best way to get around it. Any help would be greatly appreciated.

I am writing a program to install report modifications to a BOE repository. This is my first foray into the BOE SDK, so I'm still quite green. The basic steps that my program takes are:

- Look for an existing version of the report (based on title);

- If it exists, move it to an Archive folder within BOE;

- Create the new version of the report in the folder that the old version was in;

- Copy all report options that would not likely be part of the change (scheduling info, security info, format, etc., etc., etc.);

- Call infoStore.CommitBatch() to commit everything to the CMS.

Is it during the CommitBatch() that I get the exception in this post's subject. The ID number referenced is that of the new version of the report. I assume that the issue is that the SDK is trying to schedule an instance of the new version (although at this point, I am not looking to do that), and it doesn't recognize that the new version exists yet, even though creating it is part of the batch being committed. (Scheduling will be added later, if the old version had any scheduled instances.) At this point, my goal is copying the default scheduling information from the old version to the new version.

I'll start wading through the documentation and forum posts, but there's a whole slew of information, so that might take some serious time. If someone could point me in a direction, that would be most helpful. I guess what I'm looking for is the answer to "What causes the SDK to schedule an instance of a report?"

Also, I was hoping to do all of the changes to the CMS, and then atomically commit everything in one shot, so either none or all changes make it to the CMS, including scheduling new instances of new versions of the report. This exception leads me to believe that I will not be able to accomplish this task. Is that correct? If so, do you have an opinion on the approach of creating a second InfoObjects collection with the instances to be scheduled, and follow the CommitBatch() of the objects that are changeing by a separate CommitBatch() of the scheduling instances?

Thanks for the help,

Carl