Skip to Content

How can I tie a recurring instance to the instances that result from it?

I have seen this question a couple times during my tenure here and it came up again today.

The customer was interested in finding the SI_ID of a recurring instance that he just created. When I inquired as to why he said he would like to be able to find the recurring instance and any instances that result from it.

There are a couple things that you need to know when trying to do this.

People have a misconception that a recurring instance is kind of like a parent object and that each time the instance is scheduled to run it creates “child” instances that are tied to it.  This is not the case. 

A recurring instance is just a pending instance that has the unique ability to create a new instance when it runs.  The result of this is that when you create a recurring instance the SI_ID of that recurring instance will end up being the SI_ID of the next instance it creates and NOT the SI_ID of the recurring instance through its lifetime.  This means that after each run the recurring object has a different SI_ID and nothing ties the recurring instance to the instances that resulted from it in the past.

In the BO Enterprise product as it currently sits there is no definitive way of finding which instances were created by a specific recurring instance. You can get a pretty good guess by looking at schedule times and such, but due to the potential volume of recurring instances and objects it would make it almost impossible to do easily.

I went over this with the customer (my thanks to Yuri Goron at APOS Systems!) and we discussed a way to get around this by using a custom property. This works quite well and in the following code I show how to accomplish this.



How to tie a recurring report with the resulting instances in VB.NET

When you use this method you can then query with something like

“Select si_name , si_mycustomproperty from ci_infoobjects where si_recurring = 1”

 to get the recurring instances and their custom property value.  You then query for

“Select * from ci_infoobjects where si_recurring = 0 and si_instance = 1 and si_mycustomproperty =  ‘the value from the previous query'”

This will return all of the instances that were created by the recurring instance.

I hope this was helpful and good luck with your projects!


You must be Logged on to comment or reply to a post.
  • While this is a very clever bit of coding, I can’t help but feel that it is overkill.  Why not simply re-title your instances?  In the schedule, you can set the instance title to be whatever you want.  We routinely use that to indicate which prompt values were used in the schedule.
    • Hi Marshall,

      Thanks for commenting!

      That is completely legitimate and easy to implement if you have a controlled environment with everyone following strict naming conventions.  The problem is a majority of time that doesn’t seem to be the case with end users.  Everyone just uses the default template name and schedules their report.

      You also run into Joe and Sally both running the same report with the same parameters and they both name it by the naming convention then you are back in the same situation with multiple recurring reports and instances with the same name.

      Using this method removes that possibility.

      Thanks for the input Marshall as I am sure others can take your method and implement it easily and without resorting to code.

      • Another advantage of encoding the instance in a keyword or title is that those InfoObject properties are indexed in the CMS repository database.

        Custom properties reside in a BLOB, so query filtering results in all possible hits regardless of the custom property values being read into CMS memory and being filtered there.


        Ted Ueda

        • Per Marshall and Ted’s suggestion, you can add the keyword/title using the RAS SDK to the report after the fact if they have already been published.