Search Results preferred_given_name




Overview
Explore in AI Chat

Overview

IGR_IS_PERSON is an APPS-owned database view within the IGS (Student System) product family of Oracle E-Business Suite. It is documented in ETRM as an "Entry Status Organization units view," a designation that reflects its position within the prospect and inquiry-tracking branch of the student lifecycle, where individuals captured through inquiry or entry-status processing are held before they become fully enrolled learners. The view exposes person-identifying and demographic attributes for a single logical person record, scoped by operating unit, and surfaces the ROWID of the underlying row to support updatable or row-addressed processing.

Its principal role is to provide a stable, denormalized read interface over person data held in the IGR_IS_PER_ALL table, which is a multi-organization table partitioned by ORG_ID. By exposing ORG_ID alongside the person identifier, the view supports operating-unit-aware reporting and integration. Given that the search term associated with this object is "preferred_given_name," the view is frequently encountered when developers and analysts need to retrieve the preferred form of a person's forename — the name a prospect or student has elected to be addressed by, distinct from the legal GIVEN_NAME.

The view is marked VALID in the ETRM record, and the object name carries no _ALL suffix, indicating that row-level security and operating unit filtering are not automatically applied by the view itself; consumers must supply their own ORG_ID predicates where multi-org isolation is required.

Underlying Base Objects

The view is defined over a single documented base object, IGR_IS_PER_ALL, aliased as TAB in the view text. The relationship is a direct, one-to-one projection: each row in IGR_IS_PERSON corresponds to one row in IGR_IS_PER_ALL, and no joins, unions, or aggregations are performed. All twenty-six columns exposed by the view are drawn straight from the base table without expression or transformation.

Because IGR_IS_PER_ALL is a multi-organization table, the presence of ORG_ID in the view is the mechanism by which inquiry and prospect records remain segregated across operating units. The ROW_ID column is populated from TAB.ROWID, preserving the physical row address of the base record; this is significant because Oracle EBS forms and certain APIs use the ROWID as the handle for identifying and updating the current row. The ETRM metadata lists no additional referenced base objects, and no views, synonyms, or package-based logic are documented as contributing to the definition.

Key Columns

Common Use Cases and Queries

The most frequent use of this view is retrieving the preferred forename for display in inquiry-tracking reports, correspondence, and integration extracts. A typical query filters to a specific operating unit and person:

  • Listing preferred names for an operating unit: 
    SELECT inq_person_id, given_name, preferred_given_name, surname
FROM   apps.igr_is_person
WHERE  org_id = :p_org_id;
  • Resolving persons who have a preferred name distinct from the legal name: 
    SELECT inq_person_id, given_name, preferred_given_name
FROM   apps.igr_is_person
WHERE  preferred_given_name IS NOT NULL
AND    preferred_given_name <> given_name;
  • Locating a person by inquiry identifier together with status and program context: 
    SELECT inq_person_id, preferred_given_name, surname, status, program_id
FROM   apps.igr_is_person
WHERE  inq_person_id = :p_person_id
AND    org_id = :p_org_id;
  • Auditing recently changed person records for an integration or import batch: 
    SELECT inq_person_id, preferred_given_name, last_updated_by, last_update_date
FROM   apps.igr_is_person
WHERE  org_id = :p_org_id
AND    last_update_date >= :p_since_date;

Because the view carries no _ALL suffix and applies no row-level security, every query against it should include an explicit ORG_ID predicate unless cross-operating-unit reporting is intended. Since the view is a direct projection of IGR_IS_PER_ALL, update statements should target the base table rather than the view, using ROW_ID for row identification where an EBS form or API supplies it.