We are in the process of migrating our Data Services 4.2 environment into a new environment and while doing so, also go from an older SP version to the latest SP version (DS 4.2 Service Pack 10.)
However, the BODS production environment is quite critical and can’t really be brought down so rather than actually migrating, we’re essentially copying the environment so that the legacy one can be disestablished when the new one is fully up and running.
The practically zero-down-time mandate also meant that we couldn’t really disassociate the existing repos from the job server group in production before migrating/copying them. Instead we took the nightly database backups and restored them into the new environment where we did a fresh new BODS 4.2 SP10 installation.
We used the repository manager to upgrade the repo databases to SP10. We connected them to new Job Server, did a repo resync, connected them using the co-located IPS (4.2 SP5) and removed the older entries in the AL_MACHINE_INFO table so that only the entries for the new Job Server, Administrator and RepoManager remained, just like a freshly created SP10 repository in the same environment. This approach has worked well for us in the past.
As a sanity check, we did all the steps as per the SAP BODS Upgrade/Migration Guide online except for the first one:
However, when we try to access the migrated repositories, we get a database connection error as it is still referring back to the old environment - which is not accessible from the new environment. I double checked the AL_MACHINE_INFO entries and they are all good. Any newly created (non-migrated) repository works just fine but the migrated ones are throwing a bit of a fit.
Resyncing using the DS Server Manager and reattaching again in the IPS haven’t helped.
I’m sure we’re overlooking a very simple thing here but I cannot figure out what it is. Is there any other location in the repository that would contain a reference to the old environment? Because the error I’m getting is a DATABASE error, I do not believe that a lingering job server reference is the cause of the problem - but I cannot think of a location where a repository database would reference its own database host server within the repository .
Any suggestions would be most welcome.
ErikR 
(BOB member since 2007-01-10)