Search Results igs_ad_appl_perstat_s

Overview

IGS_AD_APPL_PERSTAT_PKG is an Oracle E-Business Suite PL/SQL package that belongs to the Oracle Student System (formerly Oracle iLearning/Student Administration) schema APPS. Its documented purpose is to manage the application personal status — that is, the personal or admission statuses associated with a person's application records — within the Admissions (IGS_AD) module. The package body encapsulates the data manipulation logic required to insert, update, lock, and delete rows in the IGS_AD_APPL_PERSTAT base table and consistently reflect changes in the IGS_AD_APPL_PERSTAT_S secure/translated table. It operates as the procedural interface through which forms, concurrent programs, and other PL/SQL components manipulate personal status data while preserving relational integrity, concurrency control, and multilingual support.

Key Procedures and Functions

The package exposes eight documented procedures and functions, each addressing a specific aspect of row lifecycle management and validation:

• INSERT_ROW — Performs the direct insertion of a new personal status record into the underlying base table. It is the low-level insert routine invoked after the appropriate primary-key and foreign-key values have been derived or validated.
• UPDATE_ROW — Applies modifications to an existing personal status row, writing changes to the base table and handling the associated secure table synchronization.
• LOCK_ROW — Obtains a row-level lock on the target record to enforce optimistic concurrency control, preventing conflicting updates from concurrent sessions.
• ADD_ROW — Higher-level wrapper that combines key lookup/validation with insertion, providing a single entry point for adding a complete personal status record.
• DELETE_ROW — Removes a personal status record from the base and secure tables, respecting referential constraints and validation rules.
• GET_PK_FOR_VALIDATION — Resolves and returns the primary-key values required to validate uniqueness or existence before a DML operation proceeds.
• GET_FK_IGS_AD_PER_STM_TYP — Retrieves the foreign-key value referencing the personal status type master (IGS_AD_PER_STM_TYP), ensuring that only valid, defined status types are associated with an application.
• BEFORE_DML — Central pre-DML hook that runs common validation and setup logic (including message stack handling and key derivation) before any insert, update, or delete executes.

Tables Accessed

The package reads and writes two documented tables:

• IGS_AD_APPL_PERSTAT — The primary base table storing application personal status records. INSERT_ROW, UPDATE_ROW, and DELETE_ROW write to this table; LOCK_ROW locks rows within it.
• IGS_AD_APPL_PERSTAT_S — The corresponding secure table carrying the translated or secured column values (for example, description fields). It is maintained in parallel with the base table to support multi-language environments.

The package additionally references IGS_AD_PER_STM_TYP master data through GET_FK_IGS_AD_PER_STM_TYP, together with supporting objects such as IGS_AD_APPL_PERSTAT_PKG (its own specification), IGS_AD_PER_STM_TYP_PKG, IGS_AD_GEN_002, IGS_SC_GEN_001, IGS_GE_MSG_STACK, IGS_PE_PERSON_BASE_V, FND_GLOBAL, FND_MESSAGE, APP_EXCEPTION, and STANDARD.

Usage Notes

IGS_AD_APPL_PERSTAT_PKG is a server-side API called by Oracle Student System application forms and by other PL/SQL components in the Admissions module whenever an application personal status must be created, changed, or removed. The metadata record confirms that the package is referenced by five other database objects, indicating it is a shared dependency rather than a top-level entry point. Because it is a package body owned by APPS with status VALID, it is invoked indirectly through its specification, most commonly from Forms-based maintenance screens and from custom extensions that adhere to the same validation and concurrency conventions. The internal BEFORE_DML hook and the foreign-key helper enforce data integrity, so callers should supply valid status-type references and rely on LOCK_ROW for consistent concurrent updates. Direct invocation from ad hoc SQL is generally discouraged in favour of the documented procedures to guarantee that both the base and secure tables remain synchronized.