Retransformation automates the process of reconciling changes in the ERD to the DSD. Retransformation selectively updates the DSD after the ERD has been changed. The DSD is left intact and only those ERD objects that changed in such a way to leave the DSD inconsistent with the ERD are implemented again. This preserves any customizing you may have done on the DSD, such as changes to table sizes, and eliminates the need to delete and add a DSD table again to make changes.
It is intended for use when you are in a DSD maintenance mode. If there is no DSD or you do not want to preserve the existing one, a transformation serves you better.
Retransformation uses Consistency Check rules to detect differences between the ERD and DSD. A rule violation is required to trigger retransformation. Simply changing the name of an entity type in the ERD does not cause retransformation but making a structural change, such as adding an entity type, does. Deletes in the ERD do not result in any retransformation changes because they are immediately applied to the DSD.
Before performing retransformation, check the technical design defaults. Even though all databases are checked for consistency, the default database specified is the one to which the retransformation adds any new tables or tablespaces. Note that if you change the default owner ID between retransformations, the result will be some tables qualified by the new ID and some by the prior ID. This is because retransformation reconciles changes in the ERD to the DSD, not changes between one setting of defaults and another setting of defaults.
The retransformation pop-up lets you select which objects are retransformed. You can use the options to select the type of retransformation, and to limit the scope of the retransformation and the RI process to implement.
|
Copyright © 2013 CA.
All rights reserved.
|
|