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

[Former Member]

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

[ted_ueda]

How are you creating the new report InfoObject?

Sincerely,

Ted Ueda

[Former Member]

This is the logic that creates the InfoObject:

// create new report version in BOE from file passed in
InfoObject newver = mainrpts.Add(infostore.PluginManager.get_PluginInfo("CrystalEnterprise.Report"));
Report rpt = (Report)newver;
rpt.Files.Add(reportFileName, 1, null);

rpt.Title = baseReportName;
rpt.ParentID = installToFolderId;

Then there is ~260 lines of code to move values from the old version of the report to the new version. I can post any relavant section that you suggest (but feel 260 lines is a bit long to include here).

As an aside, I just ran across the sample programs that schedule instances, which pointed me to the infostore.Schedule() method. I am currently NOT calling that method in my program anywhere... (That also leads me to believe that a second InfoObjects collection will be needed for scheduling the new versions of the report. Please correct me if I'm wrong.)

Thanks for the help,

Carl

[Former Member]

I figured out what was causing the report to be scheduled:

rpt.SchedulingInfo.Flags = oldrpt.SchedulingInfo.Flags;

The value returned by oldrpt was ceScheduleFlagResume (0), so apparently, the SDK tried to "resume" the new report...

Thanks for the help,

Carl

[ted_ueda]

Wowsers! That's a pretty interesting thing to have troubleshooted!

Sincerely,

Ted Ueda

[Former Member]

Ted,

I have to admit that it was kind of a guess. I was just looking through all of the ProcessingInfo members to see if anything made sense. "Flags" didn't tell me much, so I set a breakpoint to see what that value was. When I saw the Resume value, I looked it up in the SDK reference. It had a possibility of causing confusion, so I commented the line out. Lo and behold! No more exception.

So, is this a "feature", or a bug??

Carl

[ted_ueda]

It's considered "By Design" - if you commit a schedulable InfoObject with the flag set to resume, then it tries to resume it.

Sincerely,

Ted Ueda