When we want to promote a caster job from Test to Live we key it in again.

I notice there is a facility to migrate entire repositories but nothing for individual jobs.

Does change management perform this function as I can't find the docs?

Anyone written a Utility to do this?

Yours hopefully

John

Did not search very hard

http://documentation.informationbuilders.com/masterinde...n/source/topic85.htm

Seems it does it - will give it a try and report back.

Docs

That's why!

Chapter 12 was missing from the distribution CD of docs we bought but appears on the screen.

Is Change management being deprecated from caster?

Can be done tho.

in 76

Run migrspecific.bat while logged onto target system box and alter rcmigrate.properties to point at the source system.

I would suggest loading schedules one at a time and being very careful.

If you INSERT it tries to insert new keys always and the last action where it tries to insert the report caster user usually fails.

To replace you will need the same ids etc.



The screen looks nothing like that in the docs which is prob why it has been deleted from the distribution CD.

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

Just tested the copied jobs and they work fine!

I really need to set up a Sock Puppet id so it looks like I have some friends/am not talking to myself.

John,

Thanks for the thread, it will really help a lot of people. It sure helped me, I just waited until you finished...

Tom

Feeling lonely?

Reportcaster is my only friend...

Joking aside, thanks for the support and it is sometimes quite theraputic to post solutions as you are looking!

Also found out "test to live" is "change management" in wf terms and there are facilities for.

1. Dashboard
2. MRE
3. Reportcaster
4. Deploy an Application in DS

Anyone with experience of these? or do you tend to do manual copying which I have been doing till now.

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

John,

You know what they say about talking to yourself!

I have used the Change process to migrate MRE components and it does work well - once you have got it setup properly. The advantage used to be that the domain, group and components retained the same names that were sometimes "invented" when the number of characters in the name exceeded of didn't match the limits for each item (domain, group and component). So that when your fex called "Nice_new_report_on_Car_file" was put into MRE and it conflicted with an existing report name called "Nice_new_report_on_GGSales_file" and was therefore renamed to something like "xh34btys.fex", it actually remained that name when migrated to Prod from Dev.

Now, of course, there isn't the same problem as the eight char fixed length on MRE components has been removed (since 7?) and the actual domain and group names seem to function OK.

You know what I am going to say though and that is that I still, mostly, prefer to do it manually as it keeps the mind fresh on how it all hangs together

T

Question about using this technique to move Schedules ...

Doesn't the underlying FocExec library structure (MRE/Domain/StdRpt/Group/*.fex or apps/appdir/*.fex) have to be exactly the same in both environments, and populated with the same path and *.fex names?

I can't imagine the migration tool could change the path to or name of the execution code used by a schedule's task as it copies the Task entry from one repository to another. By what process would it search the target database for as 'equivalent' executable if it found the path there was different from the one named in schedule's Task data?

It seems the migrator is fine for dev->prod moves when you've got two separate WF environments, but the two-window copy-n-paste method is still the only way if you've got but one (shared) environment wherein User/OwnerID separates dev from prod.

quote:

Originally posted by hammo1j:
Docs

That's why!

Chapter 12 was missing from the distribution CD of docs we bought but appears on the screen.

Is Change management being deprecated from caster?

John,

I don't think so. I've got 2 versions of the ReportCaster Development and Administration Version 7 Release 6.1 and Higher.

DN4500787.1107 - 12 Chapters, 4 Appendices (missing ReportCaster Change Management)
DN4500787.0408 - 13 Chapters, 4 Appendices

Most probably left out by accident.

Cheers

Stu

cburt

You're right - even pointing a reportcaster at itself to move jobs retains the userid.

Unfortunately you cannot clone between userids so it is going to be 2 screen copy unless you go the whole hog and write an application to do what you want in TABLE and MODIFY. We got something that does similar in our MRE to copy domains and users etc etc so it is not impossible.

We have just upgraded to 7.65 and have two environments, dev/test and production. We are implementing change management. I was wondering if you could share any policies and procedures you may have in regard to change management.

I want to make sure we are inline with what others are doing in terms of policy. Some of the concerns that have been brought up are turn around time, who should be allowed to move reports, and report castor.



Any help is greatly appreciated. Prefer if you could share a change management policy and procedure document.

I can be emailed directly at ibrahimdo@wssu.edu