Search Results igs_ca_teach_to_load_v




Overview
Explore in AI Chat

Overview

The view IGS_CA_TEACH_TO_LOAD_V belongs to the IGS (Student System) product family within Oracle E-Business Suite, a module now classified as obsolete in the Oracle ETRM data model. Its stated purpose is to "describe the teaching calendars for the given load calendar." In practice, the view resolves and exposes the relationship between a student's default load calendar and the teaching calendar that corresponds to it, joining both calendar instances so that their identifiers, date ranges, descriptions, and alternate codes can be compared side by side within a single result set.

Because the base objects on which it depends are associated with the legacy IGS Student System, the view is not implemented in current 12.1.1 or 12.2.2 databases. It is preserved here primarily for reference and for understanding the historic ETRM documentation model. Where the view appears in a reporting or integration context, it functioned as a convenience abstraction that saved application code from repeatedly joining the load-appointment, calendar-type, and calendar-instance tables by hand.

Underlying Base Objects

The ETRM metadata lists no formally documented base objects, but the embedded view text reveals the tables referenced by the SELECT. These are:

  • IGS_ST_DFT_LOAD_APPO — the default load appointment table (aliased AP1), which establishes the mapping between a load calendar type, its sequence number, and the corresponding teaching calendar type.
  • IGS_CA_INST — the calendar instance table, joined twice: once as CI for the load calendar instance and once as CI1 for the teaching calendar instance.
  • IGS_CA_INST_REL — the calendar instance relationship table, used in nested subqueries as R1 and R2 to enforce the parent/child linkage between supervisory and subordinate calendar instances.
  • IGS_CA_TYPE — the calendar type table (CT and CT1), which is filtered on S_CAL_CAT to distinguish load calendars ('LOAD') from academic teaching calendars ('ACADEMIC').

The join structure is deliberately self-referential: the outer query matches the load instance from IGS_ST_DFT_LOAD_APPO against the teaching instance, while the nested IN clauses verify that a valid relationship exists between them through IGS_CA_INST_REL and confirm the calendar categories via IGS_CA_TYPE.

Key Columns

The view exposes twelve columns, symmetrically prefixed to separate load-side and teaching-side attributes:

The ALTERNATE_CODE columns mirror the underlying CI.ALTERNATE_CODE and CI1.ALTERNATE_CODE attributes and were typically used to map institutional calendar naming conventions across integrated systems.

Common Use Cases and Queries

Typical usage centered on reconciling load and teaching calendar definitions for enrollment, scheduling, and term validation. A representative query that retrieves the teaching alternate code associated with a load calendar would be:

  • SELECT load_cal_type, load_ci_sequence_number, teach_cal_type, teach_alternate_code FROM igs_ca_teach_to_load_v WHERE load_alternate_code = :p_load_code; — resolving the teaching alternate code from a known load alternate code.
  • SELECT * FROM igs_ca_teach_to_load_v WHERE teach_start_dt >= :p_start_date AND teach_end_dt <= :p_end_date; — filtering teaching calendars that fall within a reporting period.
  • SELECT load_cal_type, COUNT(*) FROM igs_ca_teach_to_load_v GROUP BY load_cal_type; — summarizing how many teaching calendars map to each load calendar.

Because the object is obsolete and unimplemented, these queries are illustrative only; equivalent functionality in supported EBS releases must be rebuilt directly against the current calendar instance and relationship tables.