Skip to Content
avatar image
Former Member

Migrate Business Objects from one Database to Another

Hi folks,

Sorry for asking a generic question. Not  an interviewed question.

Our client is planning to migrate Business Objects from one database to another.

Target database in not identified yet. Source is Teradata.

My client requested to document all steps to be performed during this migration though it is a small task(for instance copy/paste)

What are the pre-requisites to check before and after migrating the business objects from database to another. ( just for Reports and Universes).



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Oct 03, 2015 at 09:44 PM


    your question is related to BO CMS DB migrationĀ  or universe DB migration from one to other?


    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      At its simplest:

      Run integrity check on current universe for known issues.

      Repoint the connection, run integrity check, fix errors.

      It really does depend how you want to do it. If you're changing DBMS, the most common things to break are anything that involve dates with functions, e.g. Oracle has sysdate, SQL Server has getdate() for the current system date time. Cast and convert syntax will also vary.

      I've created the topic below on the BOB forum if you're having to recreate relative dates:

      If there is no functionality changing, then simply having a good universe designer person sat there working their way through the integrity check is sufficient for changing the connection type from one DBMS to another.

      The only complex things will be derived tables and you should refer those to the person who originally wrote them if you're not sure how to rewrite them for the new DBMS.



  • avatar image
    Former Member
    Oct 05, 2015 at 07:03 AM

    The following steps will be required to point a universe to a different RDBMS. This ofcourse assumes that the underlying data structure remains the same

    1) A new connection to be defined for the new database

    2) The data foundation to point to this new connection. Run an integrity check. It may fail as the qualification of table names are different between different RDBMS. You may need to change your table names to play around the qualifications (such as owner and schema). In case if there are any custom SQL used in derived tables, they need to be converted and validated.

    3) Once the data foundation is fixed, an integrity check on the business layer will give you the excpetions and you can look at them one by one for issues. For examples the database functions or SQL used in sub-queries may not work as expected in the new RDBMS.

    Depending on the complexity of the universe, this task may not be as simple as it may sound.

    Add comment
    10|10000 characters needed characters exceeded