Search Results student_person_number




Overview
Explore in AI Chat

Overview

IGS_AZ_STUDENTS_V is a supplementary database view owned by the APPS schema in Oracle E-Business Suite, registered under FND Design Data as IGS.IGS_AZ_STUDENTS_V. The object carries a VALID status in the ETRM 12.2.2 repository. Its View Type designation states explicitly that it is a "supplementary view used to simplify forms coding," accompanied by Oracle's standard caution: Oracle does not recommend querying or altering data through this view, because its definition may change dramatically in subsequent minor or major releases.

The view belongs to the Oracle Student System (IGS) product family, the module responsible for admissions, student records, registration, and academic advising. The IGS_AZ_ prefix indicates an advising-related construct, and the underlying entity is a student group or cohort assignment together with its associated advising hold. In practice, this view presents a joined, denormalised projection that allows a form block to display a student's identifying details, group membership, assignment period, and advising hold information in a single fetch, without the form having to coordinate multiple blocks or base tables. Its role is therefore primarily internal: it supports the student-group and advising forms shipped with the Student System, and it may incidentally be consumed by reporting or integration logic that requires a flattened student/group/hold record.

Underlying Base Objects

The ETRM metadata records no referenced base objects for this view, so the dependency information available is limited to the view's own column list and source text. The column naming nevertheless permits reasonable inference. Columns such as GROUP_STUDENT_ID, START_DATE, END_DATE, ACCEPT_ADD_FLAG, and ACCEPT_DELETE_FLAG, together with the WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN), suggest an assignment table that links a person to a student group over a dated period. The STUDENT_GROUP_ID, STUDENT_GROUP_CD, and STUDENT_GROUP_DESC columns point to a group definition entity, while GROUP_NAME and GROUP_DESC carry the group's descriptive attributes. The advising hold columns (ADVISING_HOLD_TYPE, HOLD_START_DATE, HOLD_END_DATE, NOTIFIED_DATE) originate from an advising hold entity associated with the same student and group combination.

Because the view joins person, group, assignment, and hold data, any consumer should treat the row grain as one row per group-student assignment with its current hold context. The absence of documented base objects means dependency analysis must be performed directly against the database using ALL_DEPENDENCIES or by inspecting the view source in the APPS schema.

Key Columns

  • STUDENT_FULL_NAME (VARCHAR2, 363) — the concatenated display name of the student, the column most commonly sought in searches for "student_full_name"; the 363-byte length reflects Oracle's standard person name concatenation width.
  • STUDENT_PERSON_ID (NUMBER, 15) and STUDENT_PERSON_NUMBER (VARCHAR2, 30) — the internal party identifier and the user-facing person number for the student.
  • GROUP_STUDENT_ID — the group student identifier, the likely primary key of the underlying assignment record.
  • STUDENT_GROUP_ID, STUDENT_GROUP_CD, STUDENT_GROUP_DESC — the identifier, code, and description of the student group to which the student is assigned.
  • GROUP_NAME (90) and GROUP_DESC (240) — descriptive attributes of the group.
  • START_DATE and END_DATE — the effective period of the assignment.
  • ADVISING_HOLD_TYPE, HOLD_START_DATE, HOLD_END_DATE, NOTIFIED_DATE — the type and validity window of the advising hold, and the date the student was notified.
  • ACCEPT_ADD_FLAG and ACCEPT_DELETE_FLAG — indicators of whether the student accepted addition to or deletion from the group.
  • DELIVERY_METHOD_CODE (VARCHAR2, 30) — the delivery method associated with the group or assignment.
  • ROW_ID (ROWID) — the row identifier used by the originating form block.

Common Use Cases and Queries

Report developers searching for a student's display name frequently land on this view because it exposes STUDENT_FULL_NAME alongside person identifiers. A typical lookup returns the name, group, and hold status for a given person:

  • Retrieve full names and group details for a person: SELECT student_person_number, student_full_name, group_name, student_group_cd, start_date, end_date FROM apps.igs_az_students_v WHERE student_person_id = :p_person_id;
  • List active advising holds by group: SELECT student_full_name, advising_hold_type, hold_start_date, hold_end_date, notified_date FROM apps.igs_az_students_v WHERE advising_hold_type IS NOT NULL AND SYSDATE BETWEEN NVL(hold_start_date, SYSDATE) AND NVL(hold_end_date, SYSDATE);
  • Track acceptance of group changes: SELECT student_full_name, accept_add_flag, accept_delete_flag FROM apps.igs_az_students_v WHERE student_group_cd = :p_group_cd;

Because Oracle explicitly warns that this supplementary view may change without notice, production reporting and integration should be built against the underlying IGS base tables rather than this view. Where the view must be used, it should be wrapped in a custom view or an inline query so that a definition change can be absorbed in one place.