Search Results hr_dm_migrations_v

Overview

APPS.HR_DM_MIGRATIONS_V is a reporting view in the Oracle E-Business Suite PER (Human Resources) product family. Its documented purpose is to support the Data Migration (DM) user interface that drives the hr_dm_migrations functionality, presenting migration activity in a decoded, presentation-ready form rather than exposing raw identifiers. The view is owned by the APPS schema and holds VALID status in both EBS 12.1.1 and 12.2.2, and its metadata is consistent between those releases.

The defining characteristic of this view is that it is a meaning-resolving layer. It does not simply project migration columns; it joins the base migration table to the FND application definitions and to the HR_GENERAL package's lookup decode routine so that codes such as MIGRATION_TYPE and STATUS are returned alongside their user-facing descriptions. This is precisely why a search for migration_type_meaning resolves to this object: the column MIGRATION_TYPE_MEANING is exposed here and nowhere in the underlying base table.

Underlying Base Objects

The ETRM metadata documents four referenced objects:

• HR_DM_MIGRATIONS (SYNONYM) — the driving table, aliased H1. All core migration attributes, including MIGRATION_TYPE, STATUS, the source and destination database instances, business group, dates, and the selective migration criteria, originate here.
• HR_DM_MIGRATION_REQUESTS (SYNONYM) — aliased H2, supplying the concurrent request identity. It is outer-joined to the migration table and restricted to master records via MASTER_SLAVE (+) = 'M', with the correlated subquery against H3 selecting the highest REQUEST_ID per migration.
• FND_APPLICATION_VL (VIEW) — aliased F1, supplying APPLICATION_NAME for the owning application, joined on the non-null APPLICATION_ID equality.
• HR_GENERAL (PACKAGE) — invoked twice, through HR_GENERAL.DECODE_LOOKUP, against the lookup types HR_DM_MIGRATION_STATUS and HR_DM_MIGRATION_TYPE.

Key Columns

• MIGRATION_ID — primary identifier for the migration run; the join key to HR_DM_MIGRATION_REQUESTS.
• MIGRATION_TYPE / MIGRATION_TYPE_MEANING — the raw lookup code and its decoded description from lookup type HR_DM_MIGRATION_TYPE.
• STATUS / STATUS_MEANING — the raw status code and its decoded description from lookup type HR_DM_MIGRATION_STATUS.
• SOURCE_DATABASE_INSTANCE, DESTINATION_DATABASE_INSTANCE — origin and target instances for the migration.
• BUSINESS_GROUP_ID, BUSINESS_GROUP_NAME — the HR business group in scope.
• APPLICATION_ID, APPLICATION_NAME — owning application and its display name.
• MIGRATION_START_DATE, MIGRATION_END_DATE, EFFECTIVE_DATE — execution timing attributes.
• MIGRATION_PROCESS, MIGRATION_COUNT, SELECTIVE_MIGRATION_CRITERIA — process identifier, volume, and any selective criteria applied.
• REQUEST_ID — the most recent master concurrent request for the migration; may be null where no master request exists.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

The view is typically queried to monitor migration activity, to report on migration types and statuses in readable form, or to correlate a migration with its concurrent request. Because the lookup decoding is performed inside the view, reports and integrations do not need to join FND_LOOKUP_VALUES separately.

Listing migrations by decoded type and status:

• SELECT migration_id, migration_type_meaning, status_meaning, source_database_instance, destination_database_instance FROM apps.hr_dm_migrations_v ORDER BY creation_date DESC;

Filtering a specific migration type for a business group:

• SELECT migration_id, business_group_name, migration_start_date, migration_end_date, migration_count FROM apps.hr_dm_migrations_v WHERE migration_type_meaning = :p_type AND business_group_id = :p_bg_id;

Associating migrations with their concurrent request and application:

• SELECT migration_id, application_name, request_id, status_meaning FROM apps.hr_dm_migrations_v WHERE request_id IS NOT NULL;

Because REQUEST_ID is driven by an outer join and a maximum-value subquery, consumers should treat it as nullable and use it for display or drill-down rather than as a mandatory key. All access is read-only, consistent with the view's reporting role.