Migrating BO Reports between environments

We have the standard 3 environment setup of development, testing and production. Each environment has their own report server, web server, database server, etc.

Part of our migration is to move our business objects (xi r2) reports between the servers but as of right now we need to 开发者_如何学Gomanually update the connection settings for each report. This is mildly painful now at 40+ reports and will become a nightmare as we continue.

Due to how we generate reports we cannot dynamically change the connection string when we generate the report. We are using stored procs instead of Universes because that is what the team is most familiar with.

Any suggestions would be greatly appreciated.

There is an API that you can use to programatically update this sort of thing, although I can't remember how to do it. Check out the docs provided by Business Objects - IIRC they are not publically available (at least they weren't in 2006 when I last worked with it) so you may have to get them from the vendor.

Take a look at the Report Class' ReportLogon Class in the CrystalDecisions.Enterprise.Desktop.Report Assembly of the BusinessObjects SDK. Quite a few options for changing the database connection.

I wrote something similar for a client to make bulk changes Universes and WebI reports. I would imagine that it is very similar for Crystal Reports.

Are you changing the Universe Connection or Universe themselves?

In our environment, we worked around this by having the Universes named the same between environments but they each have a different Connection by environment. This prevents needing to change each report.

I searched far and wide and it seems like this is an unusual circumstance. My final solution which seems to be okay is to have a consistent DSN connection string in each environment. This means that each connection string is effectively the same.

It still feels wrong and if anyone has other ideas that would be great.

EDIT:

This failed miserably after a little bit of testing I found out many of our stored proceedures would not run using the DSN. After that I gave up completely.