I’m having a little problem with our Oracle repository. We’ve moved the repository from one machine to another. Now, when I try and connect to it from a client machine, I get an error message that says “Cannot access network layer”.
I’m assuming this is a problem because the IP address and the instance name of the repository has changed. This information, I believe, is stored in the bomain.key file (which is encrypted, I think).
I suppose I could rebuild the repository on the new machine or something, but is there an easier way to connect to the repository? Is there something I can change in the Bomain.key file to point Business Objects to the new repository location? Wouldn’t it seem to make sense that the bomain.key file points to the Oracle alias rather than a static IP address?
Wouldn’t it seem to
make sense that the bomain.key file points to the Oracle alias
rather
than a static IP address?
Have you checked to ensure that your TNSNAMES.ORA file actually contains an alias pointing to the correct IP address? If you’ve changed the IP then the TNSNAMES will need changing as well. If your alias has changed as well, then it’s understandable that you will need to do a ‘safe recovery’ and recreate your Bomain.key.
Have you tried connecting to the repository from SQL*Plus? If this works then yup, it’s a BusObj problem.
Regards
Jonathan
Project Leader
Global Medical, Regulatory and Product Strategy (GMRPS) IS
In our environment, we have BI applications that access different databases: UDB, ORACLE and SQL Server using BusinessObjects Client 5.1 /WebIntelligence 2.6 products. We would like to have a common security Domain/login for all these applications that use BO. We were contemplating about creating a common BO repository on the enterprise server that has UDB database. The document and universe domains can be created on the same server or on the application servers with ORACLE or SQL server . Has anybody tried such an endevour and would like to share the experience?
Done it many times. It works great. The only downside is that you have to have middleware for all of the platforms on machines. Personally, I would prefer just to have the whole repository on 1 platform, just for simplicity. Since you’ll be having to give everyone multiple connectivities, why not just pick the ones that are used most? I’d be most inclined to not put any repository tables on DB2, since the connectivity to it is the most complicated (at least it used to be).
In a message dated 01-06-16 01:03:07 EDT, you write:
Done it many times. It works great. The only downside is that you have to
have middleware for all of the platforms on machines.
Agreed. It’s a more “interesting” maintenance issue with a repository spread across multiple databases / servers, but there is absolutely nothing technically wrong with it.
Personally, I would
prefer just to have the whole repository on 1 platform, just for
simplicity.
Also a good point. If the majority of the users will require one of the three platforms (the original post mentioned Oracle, DB2, and SQL Server) then consider going that route for your repository. One point: Oracle and DB2 appear to be more reliable as repositories. You will probably find that you need fewer Scan / Repair cycles if you choose one of those.
Since you’ll be having to give everyone multiple connectivities, why not just pick the ones that are used most? I’d be most inclined to not put
any
repository tables on DB2, since the connectivity to it is the most complicated (at least it used to be).
The final decision factor here could likely be licensing costs. At one of my current clients they chose DB2 for their repository because the server license for DB2 was much more cost effective (the politically correct way of saying “cheaper” ) than an equivalent for Oracle. So they are saving money by limiting their Oracle licenses to only those users that need Oracle connectivity for their data connections.
Personally I like Oracle, but it is what I have worked with the most and am the most familiar with.