Search Results igs_ad_acad_interest_s

Overview

The APPS.IGS_AD_ACAD_INTEREST_PKG package body is a server-side PL/SQL construct within the Oracle E-Business Suite (EBS) Student System / Academic Records module, delivered under the IGS application prefix. Its principal business purpose is to encapsulate the database-level data manipulation logic for the Academic Interest entity, which records a student applicant's stated academic interests — typically fields of study or programs of study captured during admissions or prospect processing.

The package follows the standard Oracle Forms / EBS table-handler pattern. It operates on the base table IGS_AD_ACAD_INTEREST and its translation/attribute table IGS_AD_ACAD_INTEREST_S, providing the row-level DML operations, locking, and key/constraint validation that a Forms block or an API caller requires. In EBS 12.1.1 and 12.2.2 the object resides in the APPS schema, is documented in ETRM as VALID, and is classified with API classification OTHER (i.e., an internal supporting package rather than a public, standalone-committed API).

Key Procedures and Functions

ETRM documents eleven procedures/functions on this package body:

• INSERT_ROW — Inserts a new academic interest record, assigning surrogate keys and populating WHO columns.
• LOCK_ROW — Acquires a row-level lock on an existing record to prevent concurrent modification, returning the validation result.
• UPDATE_ROW — Updates an existing academic interest record with modified column values and audit information.
• ADD_ROW — Composite helper that inserts and stages a new record for validation, typically invoked from Forms for a newly entered row.
• DELETE_ROW — Physically removes an academic interest record identified by its primary key.
• GET_PK_FOR_VALIDATION — Derives/looks up the primary key value to be used during validation routines.
• GET_UK_FOR_VALIDATION — Derives/looks up the unique key value to be used during validation routines.
• GET_FK_IGS_PS_FLD_OF_STUDY — Retrieves the foreign key referencing the Field of Study entity, supporting referential validation.
• GET_FK_IGS_AD_APPL — Retrieves the foreign key referencing the Admissions Application entity, supporting referential validation.
• CHECK_CONSTRAINTS — Validates business/foreign-key and uniqueness constraints before a DML operation is committed.
• BEFORE_DML — Central pre-DML routine that invokes validation, key resolution, and audit-value assignment prior to insert/update/delete.

Tables Accessed

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

• IGS_AD_ACAD_INTEREST — The primary base table holding academic interest rows. All insert, update, delete, lock, and validation operations target this table.
• IGS_AD_ACAD_INTEREST_S — The associated subordinate/attribute table (denoted by the _S suffix) used to persist additional column- or translation-level detail for the academic interest entity. Because the search term igs_ad_acad_interest_s resolves to this object, the _S table is the supporting store that the package maintains alongside the base record.

Foreign-key validation additionally depends on IGS_PS_FLD_OF_STUDY (field of study) and the admissions application entity, reached through helper packages rather than direct DML.

Usage Notes

This package is intended for internal, transactional use. It is most commonly invoked from the Admissions/Academic Interest Oracle Forms block (Pre-Insert, Pre-Update, Pre-Delete, and On-Lock triggers) and from other IGS admissions packages that maintain academic interest data. ETRM records five dependent packages, including IGS_AD_APPL_PKG (admissions applications), IGS_PS_FLD_OF_STUDY_PKG (field of study), and message utilities IGS_AD_GEN_002, IGS_SC_GEN_001, and IGS_GE_MSG_STACK. Supporting dependencies include FND_GLOBAL (WHO/audit column values), FND_MESSAGE and APP_EXCEPTION (error raising).

Because the package is classified as OTHER and is not referenced by any database object, it should be treated as a non-public implementation package. Customizations should call it through the standard Forms/API layer rather than directly, and any changes must preserve the documented primary-key, unique-key, and foreign-key validation contract enforced by CHECK_CONSTRAINTS, the GET_*_FOR_VALIDATION functions, and BEFORE_DML.