Search Results preferred_given_name




Overview
Explore in AI Chat

Overview

The view IGS_AD_RELATIONS_INT belongs to the Oracle EBS IGS — Student System product family, a module that is documented as obsolete in the ETRM reference set for releases 12.1.1 and 12.2.2. In the documented metadata the object is flagged with the description "Not implemented in this database," indicating that in the source environment from which this metadata was extracted the view was not deployed and no runtime data was available. The view is nonetheless a defined dictionary object and its text is fully recorded.

Functionally, IGS_AD_RELATIONS_INT is an interface (staging) view over the admissions/student relations interface. It exposes the rows held in the IGS_AD_RELATIONS_INT_ALL table — the "_ALL" suffix confirming that the underlying table is partitioned by operating unit through an ORG_ID column. The view's role is to surface inbound relationship and person data (surnames, given names, preferred given names, birth dates, sex, relationship codes, matching indicators, and error/status flags) for downstream processing by concurrent programs that validate and import prospective or existing persons and their relationships into the student system. The leading ROW_ID column derived from TAB.ROWID is a common convention in Oracle interface views, giving the processing program a stable handle to update each staged row (for example, writing a STATUS or ERROR_CODE after validation).

Underlying Base Objects

The documented view text selects exclusively from a single object: IGS_AD_RELATIONS_INT_ALL, aliased as TAB. No other base table, synonym, or view is referenced, and the metadata records "none documented" under referenced base objects. Every exposed column, therefore, is a direct projection of the corresponding column in IGS_AD_RELATIONS_INT_ALL, with two exceptions:

  • ROW_ID is a pseudocolumn projection of TAB.ROWID rather than a physical column.
  • ACCOUNT_NUMBER is a hard-coded literal NULL with an alias, present only to satisfy a consistent column signature expected by the interface consumer.

Because the view presents the _ALL table directly without a WHERE clause, it does not filter by ORG_ID; multi-org filtering, where required, must be applied by the calling code or by a Multi-Org secured synonym layered on top. The standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and the concurrent-manager request columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE) are carried through unchanged, confirming that the interface tables participate in the standard Oracle Applications request-tracking framework.

Key Columns

  • INTERFACE_RELATIONS_ID / INTERFACE_ID — primary and parent identifiers for the staged relationship and its interface batch.
  • ORG_ID — operating unit identifier; the view exposes it but does not restrict on it.
  • RELATIONSHIP_TYPE, RELATIONSHIP_CODE, OTH_RELATIONSHIP_TYPE — classify the relationship being imported, including a free-text "other" catch-all.
  • SURNAME, GIVEN_NAMES, MIDDLE_NAME, TITLE, PRE_NAME_ADJUNCT — name attributes of the related person.
  • PREFERRED_GIVEN_NAME — the column matched by the user's search; stores the name by which the person prefers to be addressed, distinct from the formal GIVEN_NAMES.
  • BIRTH_DT, SEX, DECEASED, DECEASED_DATE — demographic and vital-status attributes.
  • REL_PERSON_ID — links the staged row to an existing person record, where already known.
  • MATCH_IND — drives duplicate/person-match handling during import.
  • STATUS, ERROR_CODE — written back by the validation/import program to indicate success or the reason for rejection.
  • RECIPROCAL_FLAG — indicates whether the reciprocal relationship should be created automatically.
  • PERSON_NUMBER, ACCOUNT_NUMBER — person identifier; ACCOUNT_NUMBER is always NULL in this view.

Common Use Cases and Queries

Typical usage is diagnostic and pre-import inspection: confirming which interface rows remain unprocessed, which carry errors, and which already match an existing person. A representative query selects the name attributes that the user searched for:

  • SELECT interface_relations_id, interface_id, org_id, surname, given_names, preferred_given_name, status, error_code FROM igs_ad_relations_int WHERE status IS NULL ORDER BY interface_relations_id;
  • SELECT interface_relations_id, preferred_given_name, match_ind, rel_person_id FROM igs_ad_relations_int WHERE match_ind = 'Y' AND rel_person_id IS NULL;
  • SELECT status, error_code, COUNT(*) FROM igs_ad_relations_int GROUP BY status, error_code;

Because the view is tied to an obsolete product and is reported as not implemented in the documented database, these queries are of practical value only in installations where the IGS admission relations interface was actually deployed; in current environments the equivalent functionality resides in the Oracle Student Management / Campus Solutions lineage rather than in EBS 12.1.1 or 12.2.2 native objects.