Search Results igs_ps_unit_grd_schm_s




Overview

The APPS.IGS_PS_UNIT_GRD_SCHM_PKG package body is a PL/SQL API within the Oracle E-Business Suite (EBS) Student System (IGS) product family. It manages the relationship between academic units (versions) and grading schemas, providing the programmatic backbone for the IGS_PS_UNIT_GRD_SCHM entity and its translated/description table IGS_PS_UNIT_GRD_SCHM_S. In the Higher Education domain of EBS, a grading schema defines the valid grades, grade scales, and related rules that may be awarded for a unit offering. This package binds a grading schema to a specific unit version, ensuring that the appropriate assessment regime is enforced consistently across registrations, attempts, and results processing.

The package is classified as an "OTHER" API in ETRM, meaning it is a table-handler style API rather than a public business-facing wrapper. It encapsulates the low-level DML and validation logic required to maintain the unit-to-grading-schema association, including constraint checking and primary/unique/foreign key resolution. The object is status VALID and owned by the APPS schema, which is the standard deployment convention for EBS seed and product code.

Key Procedures and Functions

The package body exposes eleven documented procedures and functions, structured around standard EBS table-handler patterns:

  • INSERT_ROW — Inserts a new row into the base table, managing surrogate key generation and audit columns.
  • UPDATE_ROW — Updates an existing row identified by its primary key, applying modified attributes and audit stamping.
  • DELETE_ROW — Removes an existing association row from the base table.
  • ADD_ROW — Combines insert and update semantics, adding a row if absent or updating it if present, a common convenience wrapper.
  • LOCK_ROW — Acquires a row-level lock on the target record, typically via SELECT ... FOR UPDATE, to serialize concurrent modifications.
  • GET_PK_FOR_VALIDATION — Resolves the primary key for the supplied row, used by validation routines to confirm record identity.
  • GET_UK_FOR_VALIDATION — Resolves the unique key, supporting duplicate detection and uniqueness enforcement.
  • GET_FK_IGS_PS_UNIT_VER — Fetches the foreign key referencing the unit version, validating the parent unit context.
  • GET_FK_IGS_AS_GRD_SCHEMA — Fetches the foreign key referencing the grading schema, validating the schema context.
  • CHECK_CONSTRAINTS — Performs validation against business and database constraints before DML is committed.
  • BEFORE_DML — A pre-DML hook that runs mandatory checks, message-stack handling, and audit preparation.

Tables Accessed

The package reads and writes the following documented tables via APPS synonyms:

  • IGS_PS_UNIT_GRD_SCHM — The base table storing the association between a unit version and a grading schema. This is the primary target of all DML operations.
  • IGS_PS_UNIT_GRD_SCHM_S — The corresponding translated/description table, holding language-specific descriptive text for the association.
  • DUAL — Used for single-row queries, typically in key generation and validation helpers.

Dependencies also include IGS_AS_GRD_SCHEMA_PKG and IGS_PS_UNIT_VER_PKG, whose own table handlers support foreign-key validation, along with utility routines from FND_GLOBAL, FND_MESSAGE, IGS_GE_MSG_STACK, and APP_EXCEPTION for context, messaging, and error propagation.

Usage Notes

This package is typically invoked indirectly rather than called directly by end users. It is referenced by five other database objects, indicating it operates as a building block for higher-level Student System APIs and forms-based maintenance of unit grading schemas. Typical invocation paths include the Oracle Forms UI for unit and grading schema setup, concurrent programs that bulk-load or validate unit grading schema assignments, and custom PL/SQL extensions that need to create or maintain these associations programmatically. Because it is a table-handler body, callers should respect the standard EBS locking and validation sequence: LOCK_ROW before UPDATE_ROW or DELETE_ROW, and rely on BEFORE_DML and CHECK_CONSTRAINTS to enforce data integrity before commit. Direct DML against the underlying tables is discouraged, as it bypasses the audit and message-stack handling implemented within this package.