I couldn’t find an answer to this in here. All I couuld was about migrating RC Respoitories. These are all New RC Jobs which were created in a test environment.

I'm thinking: No, mainly due to the randomly generated schedule IDs and the way they are used in the RC management tables...

So, I'll "Ask The Experts" first...

Can Report Caster jobs (schedules) be migrated from one environment to another environment (test to production)? Is that a normal migration process? If so, where's the documentation?

Thanks in Advance, Douglas Lee

This message has been edited. Last edited by: Doug,

API?

Hi,

Use the Report Caster Change management utility.

To access go to the server where the distribution server is installed. Select Start\programs\information builders\Reportcaster xx\database migration and utilities\change management

It should ask you if you want to modify your rcmigrate.property now
select yes then follow the screen prompts.

I'm not sure where IBI's documentation is on it as we developed our own based on what you would put in for our servers.

A few tips.

Map a drive to the Test Box from your prod box before starting.

When it ask you for where the "old" repository is select the dserver.xml from your Test box

CLH,

This seems to be for migrating the RC Repositories, not the New Schedules themselves. Unless "repository" = "schedules"? Or, am I missing something here?

Hi,

After it goes thru it's setup it will let you select individual schedules and or address books that you can then either insert in your production environment or in the case of an existing schedule replace.

We usually use replace as we have over 5,000 schedules and replace will do an insert if it doesn't find the schedule.

Note this assumes that you have kept everything the same between test and prod so that the schedules can find the location of the code. The only issue we have found with using it is that it has a tendancy to loose the execution ID.

Crystal

Thanks Crystal,

What happens if there is a schedule id "12345678" in production already when doing the replace? Or is that covered in the caveat: "Note this assumes that you have kept everything the same between test and prod so that the schedules can find the location of the code." which means that this will not happen? This would only be the case if someone added a schedule id in the production (destination) environment which happens to have the same schedule id as that of one in the source environment.

Thanks,
Douglas Lee

BTW: I have another RC question which I'll cover in a new post: "Schedule a RC job from a System Scheduler"...

Hi,

It also uses owner id in there. But yes the schedule could be overwritten. We avoided this as we moved the schedules from dev to test and then to prod.

I suppose you could run a report first create hold files and then use match to see if there were any in your production environment that already had the same keys as the ones you wish to move.

Crystal

Good Answer
Thanks Crystal... I'll close this now as [SOLVED]