Search Results igs_ca_da_inst_pkg




Overview
Explore in AI Chat

Overview

IGS_CA_DA_INST_PKG is an Oracle EBS Applications (APPS) schema PL/SQL package belonging to the Student Systems / Student Records family of modules (the IGS_ prefix denotes the Oracle Student System, now marketed as Oracle Student Management / Campus Solutions-adjacent functionality within the E-Business Suite Higher Education footprint). The package operates within the Calendar (CA) subsystem and specifically manages the "Day Instance" entity — a calendar day instance. In IGS terminology, day instances represent the concrete occurrences of a day within a defined calendar instance, allowing the institution to define working days, teaching days, and non-teaching days that feed into scheduling, attendance, examination sessions, and fee calendar logic.

The package is classified as an "OTHER" API type rather than a public or private API, indicating that it provides mostly internal, table-centric access logic rather than a formally published business interface. Its function is to encapsulate the DML operations, locking, primary- and foreign-key validation, and constraint enforcement for the IGS_CA_DA_INST table, ensuring that day-instance records remain consistent across the many dependent packages that consume them.

Key Procedures and Functions

  • INSERT_ROW — Inserts a new day-instance record into IGS_CA_DA_INST with the supplied values, applying defaulting and validation logic prior to the physical insert.
  • LOCK_ROW — Obtains a row-level lock on an existing day-instance record to serialize concurrent updates and prevent lost-update conflicts during transaction processing.
  • UPDATE_ROW — Modifies an existing day-instance record, re-validating constraints and foreign keys before committing changes.
  • ADD_ROW — Provides a higher-level creation routine, typically wrapping INSERT_ROW together with internal identifier derivation so downstream callers can add a day instance without manually computing all key attributes.
  • DELETE_ROW — Removes a day-instance record, subject to referential-integrity checks against child entities.
  • GET_PK_FOR_VALIDATION — Returns the primary-key components for a given day instance so that callers can validate existence or pass the key into related validation routines.
  • CHECK_CONSTRAINTS — Central routine that enforces the business and referential constraints applicable to a day-instance row, invoked by the insert, update, and delete paths.
  • BEFORE_DML — A pre-DML trigger-style handler invoked before insert, update, or delete to populate audit columns and derive default values.
  • GET_FK_IGS_CA_INST — Resolves the foreign-key reference to the parent calendar instance (IGS_CA_INST) for a day instance.
  • GET_FK_IGS_CA_DA — Resolves the foreign-key reference to the parent calendar day (IGS_CA_DA) for a day instance.

Tables Accessed

The package operates against a single documented base table, IGS_CA_DA_INST (accessed via an APPS synonym). This table stores the individual day-instance rows that relate a calendar instance to a calendar day. The GET_FK procedures reference the parent keys used by IGS_CA_INST and IGS_CA_DA, but the package's own DML is confined to IGS_CA_DA_INST. Reads and writes are performed through the standard INSERT, UPDATE, DELETE, and SELECT patterns exposed by the procedures above.

Usage Notes

IGS_CA_DA_INST_PKG is referenced by fourteen other APPS packages, indicating that it sits low in the dependency hierarchy and serves as a shared data-access layer. Documented dependents include IGS_CA_DA_PKG, IGS_CA_INST_PKG, IGS_CA_DA_INST_OFST_PKG, IGS_CA_DA_INST_PAIR_PKG, IGS_CA_INS_ROLL_CI, and various fee and graduation packages such as IGS_FI_FEE_RET_SCHD_PKG, IGS_FI_F_CAT_CA_INST_PKG, IGS_GR_CRMN_PKG, and IGS_AS_EXAM_SESSION_PKG. Because of this breadth, it is typically invoked indirectly — from calendar maintenance forms, day-instance generation concurrent programs, rollover processes, and examination-session scheduling logic — rather than called directly by end users. Custom code extending the Student System should treat it as an internal implementation package: prefer the higher-level IGS_CA_DA_INST_PKG callers or public APIs, and be aware that any signature change would cascade across the fourteen dependent packages listed in the ETRM metadata. It exists in both 12.1.1 and 12.2.2 environments under the APPS schema with VALID status.