Kbase P110026: How to upgrade a Dynamics repository to OpenEdge
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
9/9/2010 |
|
Status: Verified
GOAL:
How to upgrade a Dynamics repository to OpenEdge
GOAL:
How to migrate the Dynamics ICFDB to OpenEdge 10.
GOAL:
What are the migration paths for Dynamics to OpenEdge?
FACT(s) (Environment):
Progress 9.1D
Progress 9.1E
OpenEdge 10.0B
OpenEdge 10.1x
OpenEdge 10.2x
Dynamics 1.1A
Dynamics 2.0A
Dynamics 2.1A
Dynamics 2.1B
Windows
FIX:
The migration paths listed below essentially comprise of running the DCU against the repository in question, in order to load the appropriate DCU schema patches. Then starting a multi user broker for the repository so that a connection can be made to it from a Dynamics session, and the necessary ADO files loaded. When the ADO load is complete, the session must be re-started before use. Any deviation from this method during the migration is noted at the appropriate points. Always refer to the Release notes when performing the migrations below.
The information below lists the migration taking place, the patch numbers applied by the DCU, the number of ADO's loaded and the final DB version sequence of the ICFDB after migration. For Dynamics 1.1A03 the DB version sequence of the ICFDB should start at 20.007.
Version DCU Patch No. of ADO's loaded DB Version
1.1A03 -> 2.0A ICFDB020008 2637 20.013
ICFDB020009
ICFDB020010
ICFDB020011
ICFDB020012
ICFDB020013
2.0A -> 2.0A01 ICFDB020014 70 20.01.5
ICFDB020015
2.0A01 -> 2.0A02 ICFDB020016 2777 20.017
ICFDB020017
Upgrading the repository with temp fixes 2.0A0201 and 2.0A0202 consisted of unpacking some fixes into the Dynamics install directory and then loading some specific ADO's into the repository. In terms of migrating to 2.1A these temp fixes are unnecessary, and upgrading directly from 2.0A02 -> 2.1A can also be performed.
2.0A02 -> 2.0A0201 Follow the details in the READMESP.txt that come with the temp fix
2.0A0201 -> 2.0A0202 Follow the details in the READMESP.txt that come with the temp fix
Run 'remove_orphans.p' against the 2.0A02/2.0A0202 repository. (See note below). I have placed this note here because the 2.0A02/2.0A0202 repository is required to run this fix regardless of migration path chosen. Even though the 2.1A temp fix, or 2.1A01 is required in order to get the fix program itself. However, since the fix can also be run later against a 2.1A repository (with a 2.0A02/2.0A0202 repository), depending on upgrade circumstances it is recognized that this may not be the actual chronological place that this fix program is run.
Upgrading to 2.1A can be done using one of the following migration paths.
2.0A02 -> 2.1A ICFDB020018 3332 20.022
ICFDB020019
ICFDB020020
ICFDB020021
&.nbsp; ICFDB020022
2.0A0202 -> 2.1A ICFDB020018 3332 20.022
ICFDB020019
ICFDB020020
ICFDB020021
ICFDB020022
After upgrading to 2.1A via the DCU and after static objects have been re-compiled the static SDO label update program 'addlabelstaticsdo.p' should be run manually. This is necessary if the application uses static SDO's. See the Dynamics 2.1A release notes for more information on this update program. These release notes also document that 'migrateEntityFieldstodatafields.p' should be run at this point, but this is not correct. This program should only be run when upgrading to 2.0A02. This is a known documentation issue logged with Development as Bug# 20040206-001.
2.1A -> 2.1A01 ICFDB020023 9 20.023
2.1A01 -> 2.1A02 ICFDB020024 90 20.025
ICFDB020025
Before converting the repository to OpenEdge, truncate the bi file and convert it to OpenEdge format with conv910:
In Progress version 9 (9.1D or 9.1E) do:
proutil icfdb -C truncate bi
Then in OpenEdge 10.0B do:
.proutil icfdb -C conv910
2.1A02 -> 10.0B ICFDB020026 176 100.002
ICFDB100001
ICFDB100002
10.0B -> 10.0B01 None None 100.002
There are no database changes or ADO's to load between 10.0B and 10.0B01.
10.0B01 -> 10.0B02 ICFDB100003 79 100.003
10.0B02 -> 10.0B03 ICFDB100004 591 100.004 (Upgrade to 10.1A here)
10.0B03 -> 10.0B04 ICFDB100005 2 100.005
10.0B04 -> 10.0B05 None None 100..005
There are no database changes or ADO's to load between 10.0B04 and 10.0B05.
The supported migration paths to 10.1A are from 2.1B01 and 10.0B03 only so in order to upgrade to Dynamics 10.1A there are two possible upgrade paths, from 2.1B01 and from 10.0B03. Before upgrading, the repository must be at the DB Version level for one of these Dynamics versions. In both cases the 10.1A DCU must be run with a DCSETUPTYPE of Migrate100Setup (10.0B03) or Migrate21Setup (2.1B01). See the 10.1A Readme for more details how to upgrade to 10.1A.
10.0B03 -> 10.1A ICFDB101001 59 101.001
In order to upgrade from 2.1B01, check the repository is at the correct DB Version level of 20.029. Then if this is the case, convert the repository to OpenEdge 10.1A by truncating the bi file and converting it to OpenEdge format with conv910:
In Progress version 9.1E do:
proutil icfdb -C truncate bi
Then in OpenEdge 10.1A do:
proutil icfdb -C conv910
2.1B01 -> 10.1A ICFDB101001 3474 101.001
10.1A -> 10.1A01 ICFDB101002 8 101.002
10.1A01 -> 10.1A02 None None 101.002
Migrations from 2.1x to 10.1A01 and migrations from 10.0Bx to 10.1A01 are not supported. Only upgrades from 10.1A are supported to 10.1A01.
There were no Repository data updates between 10.1A01 and 10.1A02 and thus no new release was created for 10.1A02. To upgrade to 10.1A02 from 10.1A, simply run the DCU as normal. As with 10.1A01, migrations directly to 10.1A02 from 2.1Bx or 10.0Bx are not supported. It is necessary first to migrate to 10.1A, then upgrade to 10.1A02.
These migrations must use an OpenEdge 10.1A installation without any service packs added.
To upgrade to .OpenEdge 10.1B, there are three possible supported migration paths as follows:
2.1B02 -> 10.1B - The repository should begin at version 020030. The DCU should use the session type 'Migrate21Setup', and the 10.1B repository should end up with a version of 101101.
10.0B05 -> 10.1B - The repository should begin at version 100005. The DCU should use the session type 'Migrate100Setup', and the 10.1B repository should end up with a version of 101101.
10.1A02 -> 10.1B - The repository should begin at version 101002. The DCU should use the session type 'Migrate101ASetup', and the 10.1B repository should end up with a version of 101101.
10.1A02 -> 10.1B ICFDB101101 34 101.101
For more details how to upgrade to OpenEdge 10.1B, please the see the Readme file that comes with the OpenEdge 10.1B installation.
To upgrade to OpenEdge 10.1C, there are four possible supported migration paths as follows:
2.1B02 -> 10.1C - The repository should begin at version 020030. The DCU should use the session type 'Migrate21Setup', and the 10.1C repository should end up with a version of 101201.
10.0B05 -> 10.1C - The repository should begin at version 100005. The DCU should use the session type 'Migrate100Setup', and the 10.1C repository should end up with a version of 101201.
10.1A02 -> 10.1C - The repository should begin at version 101002. The DCU should use the session type 'Migrate101ASetup', and the 10.1C repository should end up with a version of 101201.
10.1B03 -> 10.1C - The repository should begin at version 101101. The DCU should use the session type 'Migrate101BSetup', and the 10.1C repository should end up with a version of 101201.
10.1B03 -> 10.1C ICFDB101201 17 101.201
10.1C -> 10.1C01 None None 101.201
10.1C01 -> 10.1C02 None None  .; 101.201
For more details how to upgrade to OpenEdge 10.1C, please the see the Readme file that comes with the OpenEdge 10.1C installation.
To upgrade to OpenEdge 10.2A, there are five possible supported migration paths as follows:
2.1B02 -> 10.2A - The repository should begin at version 020030. The DCU should use the session type 'Migrate21Setup', and the 10.2A repository should end up with a version of 102001.
10.0B05 -> 10.2A - The repository should begin at version 100005. The DCU should use the session type 'Migrate100Setup', and the 10.2A repository should end up with a version of 102001.
10.1A02 -> 10.2A - The repository should begin at version 101002. The DCU should use the session type 'Migrate101ASetup', and the 10.2A repository should end up with a version of 102001.
10.1B03 -> 10.2A - The repository should begin at version 101101. The DCU should use the session type 'Migrate101BSetup', and the 10.2A repository should end up with a version of 102001.
10.1Cxx -> 10.2A - The repository should begin at version 101201. The DCU should use the session type 'Migrate101CSetup', and the 10.2A repository should end up with a version of 102001.
For more details how to upgrade to OpenEdge 10.2A, please the see the Readme file that comes with the OpenEdge 10.2A installation.
To upgrade to OpenEdge 10.2B, the migration paths are identical to those for OpenEdge 10.2A.
There were no changes to the repository between 10.2A and 10.2B. Moving from 10.2A to 10.2B does not require a migration.
For more details how to upgrade to OpenEdge 10.2B, please the see the Readme file that comes with the OpenEdge 10.2B installation.
.