Results for “date_alias_description”

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

Overview

The view IGSFV_CAL_PRD_EVNT_TYPE_PAIRS is an information-retrieval object within the Oracle E-Business Suite IGS – Student System product family. In the ETRM 12.1.1 / 12.2.2 documentation it carries the classification "Obsolete," and the implementation metadata explicitly records "Not implemented in this database," indicating that the object is documented for reference and lineage purposes rather than shipped as an active runtime artifact in current installations.

Functionally, the view presents the entity Calendar Period Event Type Pairs, described in the metadata as the combination of date aliases into pairs. Date aliases in the Student System represent symbolic references to significant dates (for example, term start or census date) that calendars and event-type processing logic consume. By pairing one alias with a related alias, the view exposes the directional relationship between two dated events, together with their human-readable descriptions and standard audit attributes. Its role in reporting and integration is to supply a denormalized, read-only projection suitable for extracts, validation checks, and referential rendering of pairing rules without requiring consumers to join the underlying alias tables manually.

Underlying Base Objects

The metadata records that the view is defined over three base objects: IGS_CA_DA_PAIR, IGS_CA_DA (referenced twice, aliased as DA1 and DA2), and no additional documented references. The view text confirms an inner-join construction in which the pairing table IGS_CA_DA_PAIR is the driving table, joined to the alias table IGS_CA_DA on two independent keys:

• DA.DT_ALIAS = DA1.DT_ALIAS resolves the primary alias and its description.
• DA.RELATED_DT_ALIAS = DA2.DT_ALIAS resolves the related alias and its description.

Because both joins are equi-joins without outer-join syntax, a pairing survives in the result set only if both aliases exist in IGS_CA_DA. The view is declared WITH READ ONLY, so it can never be used as a DML target. The ETRM metadata lists no owner and no separately documented base objects beyond those embedded in the view text, so the three tables above constitute the complete documented lineage.

Key Columns

The exposed column list is small and purpose-built:

• DATE_ALIAS – the primary date alias in the pair, sourced from DA.DT_ALIAS.
• RELATED_DATE_ALIAS – the counterpart alias that the primary alias is paired with, from DA.RELATED_DT_ALIAS.
• DATE_ALIAS_DESCRIPTION – the descriptive text of the primary alias drawn from DA1.DESCRIPTION.
• RELATED_DATE_ALIAS_DESCRIPTION – the descriptive text of the related alias drawn from DA2.DESCRIPTION.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE – the standard WHO audit columns carried from IGS_CA_DA_PAIR, supporting traceability of when and by whom each pairing was defined or amended.

Note that the physical column names in the select list (DT_ALIAS, RELATED_DT_ALIAS) do not include an explicit alias clause in the documented view text, whereas the reported column names use the DATE_ALIAS naming convention; consumers should verify actual exposed names against their instance's data dictionary before hard-coding references.

Common Use Cases and Queries

Typical usage centers on enumerating and validating alias pairings as configured for calendars and event-type processing.

• Full pairing inventory: SELECT date_alias, related_date_alias, date_alias_description, related_date_alias_description FROM igsfv_cal_prd_evnt_type_pairs ORDER BY date_alias;
• Description lookup for a specific pair: SELECT * FROM igsfv_cal_prd_evnt_type_pairs WHERE date_alias = :p_alias;
• Reverse-direction analysis: filtering on related_date_alias to identify which primary aliases point to a given target date.
• Audit review: selecting the WHO columns to determine when a pairing was last maintained.

Because the object is flagged obsolete and not implemented in the documented database, references should be confirmed against the target environment, and any replacement functionality introduced in later Student System releases should be preferred for new development.