Results for “assessable_ind”

9 results




AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGS_PS_UNIT_VER_HIST is a view owned by the APPS schema in the Oracle E-Business Suite Student System (IGS) product family. It exposes the historical version records of program units — the academic building blocks (subjects, modules, courses of study at the unit level) that make up a program of study in the Student System. Because institutions routinely revise unit definitions between academic periods — altering credit points, contact hours, coordinators, assessment flags, and enrollment indicators — EBS maintains a versioned history rather than overwriting the live record. This view surfaces that historical dimension, letting consumers reconstruct what a unit looked like at any point delimited by HIST_START_DT and HIST_END_DT.

The view is intended for reporting, reconciliation, and integration scenarios where the current-state unit record is insufficient: retrospective audit of program structure, point-in-time extracts for government or accreditation returns, and ETL into data warehouses that must preserve slowly-changing dimensions. As a view it holds no data of its own and is always read-only; all DML must target the underlying base tables.

Underlying Base Objects

The ETRM metadata documents no referenced base objects for this view, and the view text is presented in aliased form (TAB.column_name), which confirms the projection is drawn from a single driving source table with the alias TAB. In an IGS implementation that source is the version-history table for program units, corresponding to the IGS_PS_UNIT_VER table family. The absence of documented base objects in ETRM reflects that the metadata catalog does not resolve the view's dependency graph; DBAs should confirm the current definition in the target instance via DBA_VIEWS.TEXT or DBA_DEPENDENCIES rather than assuming the base object is static across patch levels.

Because the view is a thin projection — the select list maps one-to-one against TAB columns with no joins, aggregation, or filter predicates visible in the excerpt — it inherits the row granularity of its base table: one row per unit code / version number combination, with historical effective dating carried on each row.

Key Columns

Common Use Cases and Queries

The most frequent use is a point-in-time reconstruction of a unit for a reporting date, and a full history trace for a single unit code. Sample queries:

  • Point-in-time listing: SELECT unit_cd, version_number, title, unit_status, enrolled_credit_points FROM igs_ps_unit_ver_hist WHERE TRUNC(SYSDATE) BETWEEN hist_start_dt AND NVL(hist_end_dt, TRUNC(SYSDATE));
  • Version trace: SELECT unit_cd, version_number, hist_start_dt, hist_end_dt, hist_who, unit_status FROM igs_ps_unit_ver_hist WHERE unit_cd = :unit_code ORDER BY version_number, hist_start_dt;
  • Historical load extract: SELECT unit_cd, version_number, title, contact_hrs_lecture, contact_hrs_lab, billing_hrs FROM igs_ps_unit_ver_hist WHERE hist_start_dt >= :from_date AND hist_start_dt < :to_date;
  • Self-service availability audit: SELECT unit_cd, version_number, ss_enrol_ind, ss_display_ind FROM igs_ps_unit_ver_hist WHERE ss_enrol_ind = 'N';

Because the view is not effective-dated by the framework automatically, every query must apply its own HIST_START_DT / HIST_END_DT predicate to avoid returning overlapping versions.