Search Results get_fk_igs_uc_offer_conds
Overview
IGS_UC_COND_DETAILS_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, associated with the IGS (Student Systems / Oracle Student System) product family and the UC (Undergraduate Conditions) module. It is classified in the ETRM repository under the generic API classification "OTHER," indicating that it is an internally generated, table-level maintenance package rather than a public business API. Its principal role is to encapsulate DML and validation logic for the IGS_UC_COND_DETAILS table, which stores the individual detail lines that make up an undergraduate offer condition. Each condition detail carries attributes such as the condition category, condition name, condition line number, abbreviation, grade mark, points, subject, and free-text condition text.
The package declares AUTHID CURRENT_USER, meaning its procedures execute with the privileges of the invoking user and rely on APPS synonyms for object resolution. The embedded header comment (IGSXI13S.pls 115.5, dated December 2002) indicates the package has been stable since the earlier Oracle Student System releases and remains present through 12.1.1 and 12.2.2.
Key Procedures and Functions
The package exposes nine documented program units:
- INSERT_ROW — Inserts a new condition detail record, accepting the full set of condition detail columns plus a mode flag (default 'R'). Returns the new ROWID.
- LOCK_ROW — Issues a pessimistic lock against an existing condition detail identified by its ROWID and key columns, used to serialize concurrent edits before update or delete.
- UPDATE_ROW — Updates an existing condition detail record, taking the ROWID and the full column set plus the mode flag.
- ADD_ROW — Performs an insert-or-update style add operation, returning the ROWID through an IN OUT NOCOPY parameter.
- DELETE_ROW — Removes a condition detail row identified by ROWID.
- GET_PK_FOR_VALIDATION — Boolean function that validates the primary key combination of condition category, condition name, and condition line, returning TRUE when a matching row exists.
- GET_FK_IGS_UC_OFFER_CONDS — Validates the foreign key relationship from a condition detail back to its parent offer condition, using the condition category and condition name. This is the procedure most closely associated with the user search term "get_fk_igs_uc_offer_conds" and is the standard FK-check routine generated for the parent-child relationship between offer conditions and their detail lines.
- GET_FK_IGS_UC_REF_OFF_ABRV — Validates the foreign key from the condition detail's abbreviation to the IGS_UC_REF_OFF_ABRV reference table.
- BEFORE_DML — Internal pre-DML hook that enforces business and referential integrity rules before insert, update, or delete actions are committed.
Tables Accessed
The documented base table is IGS_UC_COND_DETAILS, accessed through its APPS synonym. All INSERT_ROW, UPDATE_ROW, ADD_ROW, DELETE_ROW, and LOCK_ROW operations target this table. GET_PK_FOR_VALIDATION and BEFORE_DML query it to confirm key existence and to run pre-DML validation. The FK validation routines additionally consult the referenced parent and lookup tables — IGS_UC_OFFER_CONDS and IGS_UC_REF_OFF_ABRV — to confirm that referenced values exist before the detail row is written.
Usage Notes
The package is invoked from the Oracle Forms-based maintenance screens for undergraduate offer conditions, where the form triggers call INSERT_ROW, UPDATE_ROW, DELETE_ROW, and LOCK_ROW as the user commits changes to condition detail lines. The GET_FK_* routines are typically called by the form's validation logic when a user selects or changes a parent offer condition or abbreviation. The package is also referenced by two other packages in the ETRM dependency graph, indicating that it participates in a small internal call graph rather than being a public integration API. Custom code should avoid calling these procedures directly where possible, and instead treat IGS_UC_COND_DETAILS_PKG as an internal implementation detail of the Oracle Student System; direct DML against IGS_UC_COND_DETAILS bypasses the validation enforced in BEFORE_DML and is not recommended.