Search Results get_pk_for_validation




Overview

IGS_OR_INSTITUTION_PKG is a PL/SQL package in the APPS schema belonging to the Oracle Student System (formerly Oracle iLearning / Oracle Student Systems), which provides the academic and institutional foundation for higher-education institutions running EBS. In EBS 12.1.1 the module is delivered as part of the Oracle Student System family, and it remains in the 12.2.2 code environment largely unchanged since the 12.1.1 file version (IGSOI02S.pls 115.5). The package is a declarative-integrity validation utility: it centralizes the lookups and referential checks associated with the IGS_OR_INSTITUTION entity — the table that stores institution codes used throughout the Student System.

Its purpose is threefold: to validate the primary key of an institution record before insert or update, to expose foreign-key resolution routines so dependent tables and forms can confirm they reference a valid institution attribute, and to enforce the business rules implicit in the coded columns of the institution definition (institution status, institution type, control type, and government institution code). The package is declared with AUTHID CURRENT_USER and does not own any schema objects; it operates through APPS synonyms.

The object is documented in ETRM with API classification OTHER. It is referenced by 10 other packages, making it a widely used dependency in the Student System validation layer.

Key Procedures and Functions

  • GET_PK_FOR_VALIDATION — returns a BOOLEAN indicating whether the supplied institution code corresponds to a valid primary key in the institution table. This is the routine the user searched for; it is the entry point used by client code to perform a primary-key existence check before persisting an institution record.
  • GET_FK_IGS_OR_GOVT_INST_CD — resolves and validates the foreign-key relationship to the government institution code, confirming that the referenced government body is defined.
  • GET_FK_IGS_OR_INST_STAT — validates the institution status foreign key, ensuring the supplied status code is a valid member of the institution-status lookup.
  • GET_FK_IGS_OR_ORG_INST_TYPE — validates the institution type foreign key against the institution-type lookup values.
  • GET_FK_IGS_OR_ORG_IN_CTLTYP — validates the institution control type foreign key, checking the control-type code assigned to the institution.

The four GET_FK routines follow a consistent naming convention: GET_FK_<table name>. This pattern makes their intent self-documenting and allows generic validation frameworks to discover and invoke them by constructing the procedure name from the target table.

Tables Accessed

ETRM documents the tables referenced only through APPS synonyms; no explicit table list is published. By naming convention and function, GET_PK_FOR_VALIDATION operates against IGS_OR_INSTITUTION, verifying the institution code supplied by the caller. The four foreign-key procedures read the base lookup tables that supply the government institution code, institution status, institution type, and institution control type values respectively. Because the package performs validation only, it is expected to be read-only with respect to these tables.

Usage Notes

The package is invoked from three principal contexts:

  • Oracle Forms — institution maintenance blocks call GET_PK_FOR_VALIDATION on the institution code field and the GET_FK procedures on the status, type, control type, and government code fields, typically from WHEN-VALIDATE-ITEM triggers.
  • Concurrent programs — data-load and interface programs that import institution data use these routines to validate inbound records before staging them.
  • Custom PL/SQL — the 10 dependent packages that reference this object call it to enforce the same rules consistently rather than duplicating lookup logic.

Callers must execute the package from an APPS session (or an environment with the requisite synonyms) and should treat the BOOLEAN return of GET_PK_FOR_VALIDATION as true only when the institution code exists. Because no write operations are documented, the package is safe for use in validation-only paths, and no explicit commit logic is required by its callers.