Search Results igs_as_grd_sch_grade_pkg




Overview
Explore in AI Chat

Overview

IGS_AS_GRD_SCH_GRADE_PKG is an Oracle EBS Student Systems (IGS) package body owned by the APPS schema. It serves as the primary table-handler and validation layer for the IGS_AS_GRD_SCH_GRADE entity, which stores grade values recorded against a grade schema within the academic grading model. In institutional terms, the package encapsulates the business rules governing how individual grade entries are created, modified, locked, and validated when they are associated with a grading schema — for example, when outcomes are captured for a student attempt and mapped to the scale, bands, or classifications defined by that schema. The package is classified as OTHER in the ETRM registry rather than as a public API, which indicates that it is intended for internal use by the IGS grading sub-system and by other IGS packages rather than as a formally versioned integration interface. It is documented as VALID on both Oracle EBS 12.1.1 and 12.2.2, and the ETRM extract records nine procedures or functions, confirming it is a compact, focused DML-support package. It is referenced by seventeen other database objects, reflecting its position as a foundational dependency within the IGS assessment and grading package hierarchy.

Key Procedures and Functions

The documented program units fall into three functional groups.

  • INSERT_ROW, UPDATE_ROW, ADD_ROW — the core data manipulation entry points. INSERT_ROW creates a new grade-schema grade record; UPDATE_ROW applies changes to an existing record; ADD_ROW provides the combined or preparatory insert path used when a new row must be assembled and validated before being persisted.
  • LOCK_ROW — obtains a row-level lock on the target grade-schema grade record, ensuring that concurrent maintenance of the same grade entry cannot proceed in parallel and preserving data integrity during multi-step updates.
  • GET_PK_FOR_VALIDATION — resolves the primary key of the row under validation, allowing the validation routines to distinguish an insert from an update and to apply the appropriate key-based checks.
  • GET_FK_IGS_AS_GRD_SCHEMA and GET_FK_IGS_LOOKUPS_VIEW — foreign key resolvers. The first derives or confirms the parent grade schema to which the grade belongs; the second resolves the associated lookup value from the IGS lookups view, tying the grade to its descriptive or coded classification.
  • BEFORE_DML — the standard table-handler pre-DML trigger routine, invoked before insert, update, or delete to enforce mandatory attributes, defaults, and auditing conventions.
  • CHECK_CONSTRAINTS — performs explicit validation of the business constraints that cannot be expressed as database-level constraints, raising errors via the IGS message stack when a rule is violated.

Tables Accessed

The only base table documented for this package is IGS_AS_GRD_SCH_GRADE, accessed through its APPS synonym. All nine program units operate against this single entity: the DML routines write to it, LOCK_ROW locks rows within it, and the validation and foreign-key resolvers read it to confirm that referenced schema and lookup values are consistent. The dependency list shows that the package also relies on supporting IGS packages — notably IGS_AS_GRD_SCHEMA_PKG, IGS_AS_GRD_SCH_TRN_PKG, IGS_AS_VAL_GSG, IGS_GE_MSG_STACK, IGS_GE_NUMBER, and IGS_LOOKUPS_VIEW_PKG — to obtain schema context, generate identifiers, and report validation errors, rather than querying those structures directly.

Usage Notes

IGS_AS_GRD_SCH_GRADE_PKG is not a standalone API. It is most commonly invoked from the Oracle Forms-based grade schema maintenance windows in the Student Assessment module, where end users create and adjust grade entries, and from other IGS packages that need to record or amend a grade-schema grade as part of a broader assessment process. Its seventeen downstream referencing objects indicate that custom extensions and other IGS business logic should call this package rather than performing direct DML against IGS_AS_GRD_SCH_GRADE, so that locking, foreign key resolution, and constraint checking remain consistently enforced. Because it is classified as OTHER rather than a public API, reliance on its procedures from customer-developed code carries no compatibility guarantee across patches or upgrades, and implementations should validate behaviour following any IGS patch application. There is no documented concurrent program interface; all usage is transactional and driven from the calling form or package.