Search Results igs_uc_app_results_pkg




Overview
Explore in AI Chat

Overview

IGS_UC_APP_RESULTS_PKG is an Oracle E-Business Suite PL/SQL package body owned by the APPS schema and classified under the ETRM (E-Business Suite Technical Reference Manual) as an "OTHER" API. Its functional scope belongs to the IGS (Student Systems) product family, specifically the UC (Universities and Colleges Admissions Service, or equivalent admissions clearing) module dealing with application results. The package encapsulates the persistence and validation logic for records held in the IGS_UC_APP_RESULTS entity, providing a structured, reusable interface for creating, maintaining, and locking applicant result rows rather than allowing direct DML against the underlying tables. It depends on a number of shared infrastructure components, including APP_EXCEPTION for error handling, FND_GLOBAL for session and user context, FND_MESSAGE and IGS_GE_MSG_STACK for message resolution and stack management, and IGS_UC_APPLICANTS_PKG, IGS_UC_COM_EBL_SUBJ_PKG and its own specification for cross-entity logic. The status of the object is VALID, confirming it is compiled and operational within the EBS 12.1.1 / 12.2.2 environment.

Key Procedures and Functions

The documented API surface comprises nine procedures and functions, grouped by their role in the row lifecycle:

  • INSERT_ROW — Inserts a new application result record into the base table, applying the package's standard column defaults and validation rules.
  • UPDATE_ROW — Modifies an existing application result record, typically keyed on the primary key of the result row.
  • ADD_ROW — Provides the combined create-or-maintain entry point, handling the case where a row is added through the package's higher-level logic.
  • DELETE_ROW — Removes an application result record, respecting any referential constraints enforced by the package.
  • LOCK_ROW — Acquires a row-level lock on an application result record to support concurrent-safe maintenance and to prevent lost updates during transactional processing.
  • GET_PK_FOR_VALIDATION — Retrieves the primary key of the target row so that validation logic can confirm the record exists and is accessible before further processing.
  • GET_FK_IGS_UC_APPLICANTS — Returns the foreign key reference to the applicant record, ensuring the result is correctly associated with its parent applicant.
  • GET_FK_IGS_UC_COM_EBL_SUBJ — Returns the foreign key reference to the common eligibility subject record, linking the result to the relevant subject definition.
  • BEFORE_DML — A pre-DML hook invoked before insert, update, or delete operations to enforce mandatory attribute checks, derive default values, and maintain audit columns.

Tables Accessed

The package operates against three documented tables, resolved through APPS synonyms:

  • IGS_UC_APP_RESULTS — The primary base table holding application result records. It is the target of INSERT_ROW, UPDATE_ROW, ADD_ROW and DELETE_ROW, and the source for the LOCK_ROW and primary key lookups.
  • IGS_UC_APP_RESULTS_S — The companion secondary or shadow table associated with the results entity, maintained in step with the base table to preserve historical or translation-related data.
  • DUAL — Used for scalar evaluations and lightweight lookups within the package's PL/SQL logic.

Usage Notes

Because IGS_UC_APP_RESULTS_PKG is not referenced by any database object in the ETRM dependency graph, it is not wired into triggers, views, or other packages at the schema level; instead it is invoked explicitly by application code. In practice it is called from the Oracle Forms-based admissions and results maintenance screens that manage applicant outcomes, from concurrent programs that batch-load or import application results, and from custom extensions that need a supported, validated route into the IGS_UC_APP_RESULTS tables. The package is itself referenced by four other packages, indicating that it functions as a shared service layer for result maintenance within the IGS_UC component. Developers extending this area should call the documented procedures rather than issuing direct SQL, so that the BEFORE_DML validation, foreign key derivation, locking behaviour and message-stack error reporting are consistently applied. When troubleshooting, the dependency chain through IGS_GE_MSG_STACK and FND_MESSAGE should be inspected to interpret raised errors.