Record Migration Principles

Introduction

Migration of records can cause some real headaches. This article covers PeopleSoft’s migration defaults and behaviors for records within Application Designer, as those are particularly troublesome objects for migration so that the developer / database admin may make informed migration choices.

Definitions

A record reference within a project refers to a record object by name, without a reference to field. Line one in the following image is a record reference:

A record field reference within a project includes a field name. Line two in the preceding image is a record field reference.

Comparing

Compares are useful for preparing a migration, but should be run at the appropriate time and under the appropriate circumstances. Here are some principles to keep in mind when comparing a project with records in it:

• Compares reset flags and actions. Once a project’s flags have been set as desired, compares should be avoided, unless the developer is willing to recheck / reset all flags again.
• Record field changes do not show up in compare reports. “Compare report” refers to the diff file that shows up in Application Designer, like this:

• • The record reference comparison displays as Same / Same, even though there are record field differencesbetween the two environments. Record reference changes only show for record property value changes, such as description changes and supported db platform changes. (Record property value changes are also the only changes that show up in a compare report for record references.)
  • Delete flags are not selected by default when comparing records between environments. This is good as it makes it more difficult to accidentally drop data in the target environment, but can be a problem when trying to migrate data into the target, as Data Mover scripts will fail with either extra or missing fields.
•    Comparing with a record reference in the project removes record field references.  Before compare:

• Comparing without a record reference does not remove record field references.

• Navigate to Insert > Definitions into project
• Specify field values as follows:
  • Definition Type:  Records
  • Name: [Record name]
• Select the following:
  • Select the record name in the “Record Name” box
  • “Record Fields” in the “Related Definitions” box
• Click “Insert”

Copying

The main principle to keep in mind when copying a record to a database is whenever a record reference is included in a project, the entire record is copied as is, regardless of any record field instructions.  This means that the following principles apply:

• Record field instructions in the project are ignored, even when set explicitly, such as a “Delete” action.
• Fields previously missing / removed in the target environment will be added (or re-added).
• Fields previously added in the target environment will be removed.

With those principles in mind, the following scenarios will all result in a record in the target environment with only the RMT1 field in it having the RMT2 field added to it after it has been added in the source environment:

The following scenarios will result in the RMT2 field being removed from the record in the target environment when it has been removed from the source environment:

Here are other copying principles to keep in mind:

• Copying all of the record field references for a record does not copy the record definition. In order for the record definition itself to be copied, a reference to the record must be included. For example, if the following project were migrated, clicking on one of the RMT record field references in the target database would display the following error:

• Using the CopyProp action does not copy a record definition or record fields. The “Copy” action copies record properties, as well as all of the source database’s record fields, but CopyProp copies only the record properties. In that case, any desired record field changes must be handled individually through project record field references.In the four scenarios below, the first two would result in the removal of an extra RMT2 field in the target database, while the last two would not.

• In order to remove a field through migration, a project reference must exist for the missing record field. This is an issue when a field is removed from a record and the edit is not captured in the desired migration project. Inserting record field references to the project as described above won’t work, as the field is already missing.  To include a record field deletion in a migration project, use one of the following methods:
  • Merge in a reference from an existing project using File > Merge Projects. Be careful to include only the desired project references in the merge’s source project. It may help to
  • Copy the entire record as is by including the record reference in the project.
  • Add the desired field to the record and remove it while inside the project with Tools > Options … > Project (tab) > Insert Definition into Project (box) > “When definition is modified and saved, or deleted” selected to capture the change:

That’s it!  Good luck migrating your records 

Written by Bryan K. Elkins, Technical Manager
Copyright (c) 2016 Gideon Taylor Consulting, All Rights Reserved.