Hi,
Any help would be greatly appreciated. We have a separate universe and report domain for prod and test (same repository). We made numerous changes to the LOVs in the universe (adding sorts and descriptions, etc). We then exported the universe to test domain and the production domain. Also, both universes are named the same, but are located in test and prod domain. We changed the data source provider in the reports and pointed them to the production universe. We sent the reports to the repository–production report domain. We had to change the connections to the database as it was a new database.
Now, when we retrieve the reports, refresh the report and press the ‘values’ button for prompts, we are asked which universe we want to use (however, the report runs fine against the database when we don’t press the ‘values’ button).
As a second problem, it seems that when we select the correct universe when the reports asks, then the LOV files are updated with default information and our custom changes in the universe are lost!–tech support told us to delete the LOVs when doing these changes, and this seems to cause the LOVs to revert back to default values (rather than the LOV info we had added in designer).
Does anyone have a list of steps for moving a universe, reports & especially LOVs into a production domain when the database is also changing? Thankyou and sorry for length…
Hi,
Any help would be greatly appreciated. We have a separate universe and report domain for prod and test (same repository). We made numerous changes to the LOVs in the universe (adding sorts and descriptions, etc). We then exported the universe to test domain and the production domain. Also, both universes are named the same, but are located in test and prod domain. We changed the data source provider in the reports and pointed them to the production universe. We sent the reports to the repository–production report domain. We had to change the connections to the database as it was a new database.
As a second problem, it seems that when we select the correct universe when the reports asks, then the LOV files are updated with default information and our custom changes in the universe are lost!–tech support told us to delete the LOVs when doing these changes, and this seems to cause the LOVs to revert back to default values (rather than the LOV info we had added in designer).
Does anyone have a list of steps for moving a universe, reports & especially LOVs into a production domain when the database is also changing? Thankyou and sorry for length…
First let the users delete all the universes and LOV files. Make sure that the option export with universe of te LOV’s is turned on and in the general preferences incremental export is turned off. Purge all LOV’s before exporting the universe. This way they will be rebuild (with the definitions you made) when they are imported.
However: deleting the LOV’s after the universe is imported will lead to the LOV’s rebuilding with the default values.
Any help would be greatly appreciated. We have a separate universe and
report domain for prod and test (same repository). We made numerous changes to the LOVs in the universe (adding sorts and descriptions, etc). We then exported the universe to test domain and the production domain. Also, both universes are named the same, but are located in test and prod domain. We changed the data source provider in the reports and pointed them to the production universe. We sent the reports to the repository–production report domain. We had to change the connections to the database as it was a new database.
I sympathise with your situation having spent many hours trying to rectify such problems myself. We originally had two domains as you describe and it is not the best way we found to work. As you said you get a prompt asking which copy of the universe you want to use and there are lots of LOV problems. The custom changes you made to lists of values are stored in the .lov files - you will notice that for each LOV you customise an extra .lov file appears. Most often you find that you have to restore the defaults and then modify all the lists again when you move universes around.
Anyway, the solution we found to all this is to create multiple repositories which is surprisingly simple. If you have your test repository and want to create a production repository which is the same as the test one then take a database export of the test repository and then import it into a new database instance which will from then on be the production repository. Store the current bomain.key file somewhere for reference and delete it from it’s current location. Enter Supervisor with GENERAL/SUPERVISOR and perform a safe recovery to generate a bomain.key file for the new production repository. Enter the new repository and don’t forget to change the pointer for the document and universe domains to be the new repository as it only changes the security domain automatically.
You will now have two repositories set up that are the same but can be modified and worked with independently. To switch between them all you need to do is exchange the bomain.key files and we have set up a simple VB program to do that.
I hope this is of some help to you. Good luck if you decide to stick with multiple domains in a single repository.
Not exactly your scenario but this one has worked for me in a multi domain environment :
Our environment has three tiers (development, test, production). Our one repository reflects this with a devl, test, production universe and document domains.
We have Universe_Name in the production domain, T_Universe_Name in the test domain, D_Universe_Name in the development domain. This avoids collisions with the list of values, there is no question to which universe the report is running against, and there is no prompt asking which copy of the universe you want to use.
In practice, development is performed on D_Universe_Name, we then “save as” T_Universe_Name on our client into the BusinessObjects/Univere/TestDomain folder. When you perform the “save as”, you’ll notice that the customized LOV (the *.LOV file) is copied to the
BusinessObjects/UserDocs/T_Universe_Name folder. Ensure the designer is not Prevented from overwriting Universe (an attribute set in Supervisor).
In designer, open T_Universe_Name and export it to the test domain. Viola ! the LOV are now attached to the test universe for the users.
Once the users approve the changes in test, the universe is “save as” Universe_Name into the BusinessObjects/Universe/ProductionDomain folder.
Th same procedure is followed. Our environment is working well.
This approach works with Linked Universes also. HTH - > Best Regards, Lori S. Furda
Sage Solutions, Inc. Lori_SAGE@solution4u.com
On Thursday, November 05, 1998 9:03 AM, Lou Priest [SMTP:bolist@PHARMA.FRASER-WILLIAMS.COM] wrote:
Any help would be greatly appreciated. We have a separate universe and
report domain for prod and test (same repository). We made numerous changes to the LOVs in the universe (adding sorts and descriptions, etc). We then exported the universe to test domain and the production domain. Also, both universes are named the same, but are located in test and prod domain. We changed the data source provider in the reports and pointed them to the production universe. We sent the reports to the repository–production report domain. We had to change the connections to the database as it was a new database.