Search Results igr_i_a_itype_pkg




Overview
Explore in AI Chat

Overview

IGR_I_A_ITYPE_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the student applicant address type functionality within the Oracle Student System (IGR) product family. The package follows the standard Oracle Forms generator (auto-generated DML) pattern, encapsulating the table-handling logic for the IGR_I_A_ITYPE entity — the intersection between an application (applicant) and the address type to which it is associated (the "I" prefix denoting the intersection and "A_ITYPE" denoting applicant address type). It is classified under the ETRM as an "OTHER" API, meaning it is not a formally hardened public API but rather a supporting programmatic wrapper primarily consumed by Oracle Application Forms and by other packages within the IGR schema.

The package centralizes DML operations, primary/foreign key validation, row locking, and constraint checking against the underlying table, permitting the form layers and any dependent PL/SQL code to manipulate applicant address type records consistently without embedding SQL directly.

Key Procedures and Functions

The package exposes eight documented procedures and functions, typical of Oracle Forms-generated table handlers:

  • INSERT_ROW — Inserts a new row into the IGR_I_A_ITYPE table, populating the WHO columns (created_by, creation_date, last_updated_by, last_update_date) as required by the EBS audit convention.
  • LOCK_ROW — Issues a SELECT ... FOR UPDATE against the target row to serialize concurrent modification before update or delete operations.
  • DELETE_ROW — Deletes the identified row from IGR_I_A_ITYPE, invoked when an applicant address type association is removed.
  • GET_PK_FOR_VALIDATION — Returns the primary key column values required to validate that a row exists before performing DML.
  • GET_FK_IGR_I_APPL — Retrieves the foreign key value relating to the applicant record in IGR_I_APPL, used to confirm the parent applicant reference.
  • GET_FK_IGR_I_A_ITYPE — Retrieves the foreign key value for the address type reference in the IGR_I_A_ITYPE lookup/type table.
  • CHECK_CONSTRAINTS — Performs mandatory-column and uniqueness validations prior to insert or update, raising errors for violations.
  • BEFORE_DML — A pre-DML hook called by the other routines to enforce audit stamping and constraint checks prior to executing the insert, update, or delete statement.

No parameter lists are documented in the ETRM metadata; only the procedure names, and their ordering, are provided. Implementations should not be assumed to expose any additional parameters.

Tables Accessed

The package references two tables via APPS synonyms:

  • IGR_I_A_ITYPE — The primary table managed by this package. It stores the applicant address type records, and the package performs insert, update, delete, lock, and validation against it.
  • IGS_PE_HZ_PARTIES — The HZ party table used to validate and retrieve person/party information, typically for cross-reference of the party attached to an applicant.

Foreign key dependencies reference the IGR_I_APPL (applicant) table and the IGR_I_A_ITYPE type/lookup table, as reflected by the GET_FK_* routines.

Usage Notes

IGR_I_A_ITYPE_PKG is referenced by two other packages — IGR_IMP_004 (an import/conversion program) and IGR_I_APPL_PKG (the applicant master package) — in addition to usage within its own package body. It is therefore invoked whenever an applicant address type row must be created, changed, or removed, both from the standard applicant maintenance form and from bulk import routines. Custom code should treat this package as a supporting implementation rather than a signed public API: callers are expected to already hold the appropriate row locks and to supply correctly parsed key values. Because the package is generated from the form metadata, direct modifications are overridden during patching; extensions should be built on the surrounding application or on hardened IGR APIs. Alternative approaches include using the underlying table directly only where an equivalent generated handler is not available, and always preserving the WHO audit columns that BEFORE_DML populates.