Maintaining multiple universes for separate environments

[Former Member]

I know this is a basic question, but are there guidelines on how to manage separate universes for different versions of the same physical database structure? For example, what's a good way to manage universes for separate test environments where the table owner/qualifier is different for each environment (i.e. test1.tablename, test2.tablename, test3.tablename, prod.tablename).

[Former Member · Accepted solution]

When I create tables in my universe I don't use to include the Owner in the table names. If it is shown I delete it.

In the connection parameters I log using user test1 for the connection of test1 version universe, user test2 for the connection of test2 version of the universe, and so.

If my tables are shown including the user name I delete it by doing right click on the table , I choose Rename Table and delete the Owner's name.

This way it's easier for me because if I have to do a change in one universe, let's say test2, and it has to be replicated in test1 universe all I have to do is saving test2 universe as test1 universe changing the connection user to test1.

[Former Member · Accepted solution]

Thanks for the response. This option wouldn't work for us as we don't have the ability to sign in as the owner. The owner is a collection name to which our universe designers don't have access. Our universe designers can only sign in as themselves.

[Former Member · Accepted solution]

When I create tables in my universe I don't use to include the Owner in the table names. If it is shown I delete it

That does not always work. In many cases, I've had to connect to a server with more than one copy of the schema, and leaving the owner off results in ambiguous queries. Teradata is more likely to show this behavior than Oracle, because of the way the connectivity is managed.

[Former Member]

There are a couple of options that I will share with you.

Option one is the least work on the BOBJ side and the most work on the DBA side. The DBA must create an account with access only to the required tables (or views). This means that account does not require the qualifier (test1.table_name) and instead can reference only by table_name. Now there is no issue when migrating from test1 to test2 to prod.

Unfortunately, our DBA team didn't like that option. So I created a short VBA script, hosted in Excel, that we use to update our universe as we move it from one environment to another. We've been using it for years now, and it has been working fine. However, starting with BOBJ 4.0 they removed the option of VBA / SDK scripting from the universe, so I'm not sure what we're going to do when we get to that version.

If you're interested in having a look at the script, I've posted it on my blog here:

http://www.dagira.com/2008/03/06/using-the-designer-sdk-to-ease-migrations/

[Former Member]

Yes, we would have liked to remove the owner from the equation, but our DBA's wouldn't agree to this either.

The "scripting" solution is an interesting approach. I'm curious about whether the BO SDK would allow us to access the universe repository object and "clone" it to a new one. I think that we'll investigate that option a little further.

Thanks.