Search Results get_fk_igs_ad_cd
Overview
IGS_AD_PS_APPL_PKG is a PL/SQL package owned by the APPS schema within the Oracle E-Business Suite environment. It operates within the Student System (IGS) product family, specifically the Admissions (AD) module, and is associated with the Prospective Student subset of admissions functionality. The package functions as a table handler for the IGS_AD_PS_APPL_ALL entity, providing the standard insert, update, delete, locking, and validation services that Oracle's generated forms and business logic rely upon. Its API classification is recorded as OTHER, indicating that it is not exposed as a public concurrent or business API but rather serves as an internal maintenance layer. In Oracle EBS 12.1.1 and 12.2.2, such table handlers are generated to encapsulate DML against the underlying table, enforce referential integrity through primary and foreign key lookups, and centralize constraint checking so that higher-level admissions processes remain consistent. The package is documented as VALID, confirming that it compiles cleanly and that its referenced objects resolve correctly.
Key Procedures and Functions
The ETRM metadata records thirteen documented subprograms, which together form the standard table-handler interface:
- INSERT_ROW — Inserts a new application record into the underlying table, assigning or validating the primary key as required.
- LOCK_ROW — Obtains a row-level lock on an existing record to serialize concurrent modification before an update or delete.
- UPDATE_ROW — Modifies an existing application record, typically invoked after a successful LOCK_ROW call.
- ADD_ROW — Provides a combined add operation, commonly used by forms to create a record with derived or defaulted attributes.
- DELETE_ROW — Removes an application record from the table.
- GET_PK_FOR_VALIDATION — Resolves the primary key value used during validation processing.
- GET_FK_IGS_AD_APPL — Resolves the foreign key relationship to the parent application entity, returning the related application reference.
- GET_FK_IGS_AD_CD — Resolves the foreign key to the admissions calendar or related reference entity identified by the IGS_AD_CD prefix.
- GET_FK_IGS_AD_BASIS_FOR_AD — Returns the foreign key value linking the record to the admissions basis definition.
- GET_FK_IGS_PS_COURSE — Resolves the foreign key to the prospective student course entity.
- GET_FK_IGS_EN_STDNT_PS_ATT — Resolves the foreign key to the prospective student attendance entity.
- CHECK_CONSTRAINTS — Validates that the record satisfies all declared table constraints before the DML is committed.
- BEFORE_DML — A pre-DML hook that performs preparatory processing, such as deriving values or auditing, before insert, update, or delete operations execute.
Tables Accessed
The package references the table IGS_AD_PS_APPL_ALL through an APPS synonym. This table stores prospective student application records for the admissions module. All INSERT_ROW, UPDATE_ROW, ADD_ROW, DELETE_ROW, and LOCK_ROW operations act directly on this table, while the GET_FK procedures query related parent entities to resolve and validate foreign key values. The one documented dependency at the SYS level is STANDARD, the standard Oracle PL/SQL package that provides base language constructs.
Usage Notes
IGS_AD_PS_APPL_PKG is referenced by fifteen other packages, including IGS_ADMAPPLICATION_PUB, IGS_AD_APPL_PKG, IGS_AD_CD_PKG, IGS_AD_BASIS_FOR_AD_PKG, IGS_AD_CANCEL_RECONSIDER, IGS_AD_INT_RECONSIDER, IGS_AD_PRC_TAC_OFFER, IGS_AD_PS_APPL_INST_PKG, IGS_AD_PS_APLINSTHST_PKG, IGS_EN_STDNT_PS_ATT_PKG, IGS_PS_COURSE_PKG, and several IGS_AD_GEN and IGS_AD_IMP generation or import routines. This pattern confirms its role as a low-level persistence layer consumed by admissions business logic, concurrent processing, and forms. Customizations should invoke the package only through its documented procedures and avoid direct DML on IGS_AD_PS_APPL_ALL, since the handler enforces constraint checking and pre-DML processing that bypassing it would skip. Because the package is not a public API, extensions should generally be built on the calling packages rather than on this handler itself.