As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Moving forward, myibi is our community platform to learn, share, and collaborate. We have the same Focal Point forum categories in myibi, so you can continue to have all new conversations there. If you need access to myibi, contact us at email@example.com and provide your corporate email address, company, and name.
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
In FOCUS since 1986
WebFOCUS Server 8.2.01M, thru 8.2.07 on Windows Svr 2008 R2
WebFOCUS App Studio 8.2.06 standalone on Windows 10
Posts: 5694 | Location: United Kingdom | Registered: April 08, 2004
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.
WIN/2K running WF 7.6.4 Development via DevStudio 7.6.4, MRE, TextEditor. Data is Oracle, MS-SQL.
Posts: 154 | Location: NY | Registered: October 27, 2005
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.
Server: WF 7.6.2 ( BID/Rcaster) Platform: W2003Server/IIS6/Tomcat/SQL Server repository Adapters: SQL Server 2000/Oracle 9.2 Desktop: Dev Studio 765/XP/Office 2003 Applications: IFS/Jobscope/Maximo
Posts: 888 | Location: Airstrip One | Registered: October 06, 2006
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.