Search Results get_fk_igs_ad_per_stm_typ




Overview
Explore in AI Chat

Overview

IGS_AD_APTYP_PESTAT_PKG is a PL/SQL API package owned by the APPS schema in Oracle E-Business Suite, delivered as part of the Oracle Student System (formerly Oracle iRecruitment/Admissions family of modules) under the IGS product prefix. The package serves as the programmatic interface to the IGS_AD_APTYP_PESTAT entity, which defines the relationship between admission application types and personal status types. In functional terms, this table governs whether a given personal status (for example, residency, visa, or applicant category) is mandatory when an applicant submits an application of a particular admission application type. Administrators maintain these rules through the Admissions setup forms, and the package enforces those business rules at the database layer.

The header declares AUTHID CURRENT_USER, indicating that the package executes with the privileges of the calling user rather than the definer, which is consistent with Oracle Application Object Library conventions for table-handler style APIs. The header revision string (115.3) shows the file was last revised in 2002, typical of long-stable setup APIs that persist largely unchanged across EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The package exposes the standard table-handler API surface used throughout EBS setup entities:

  • INSERT_ROW — Inserts a new row into the underlying entity, accepting a ROWID output handle and the entity attributes, with an operational mode parameter defaulting to 'R'.
  • LOCK_ROW — Acquires a row-level lock on an existing record, used by the forms layer for optimistic concurrency control before modifications.
  • UPDATE_ROW — Updates an existing record identified by ROWID, again taking the entity attributes and a mode parameter.
  • ADD_ROW — A convenience wrapper that performs an insert-if-absent semantics, returning the ROWID of the created or existing row, commonly used during data conversion and interface loading.
  • DELETE_ROW — Deletes a single record by ROWID, applying any validation logic registered with the entity.
  • GET_PK_FOR_VALIDATION — Returns a BOOLEAN indicating whether the supplied primary key combination (admission application type and personal status type) already exists, enabling forms-level uniqueness validation.
  • GET_FK_IGS_AD_PER_STM_TYP — Validates the foreign key relationship against the personal status type reference entity, ensuring the status code is defined.
  • GET_FK_IGS_AD_SS_APPL_TYP — Validates the foreign key relationship against the admission application type reference entity.
  • BEFORE_DML — The central pre-DML routine that populates WHO columns (creation date, created by, last update date, last updated by, last update login) and performs cross-field validation before any insert, update, or delete is committed.

Tables Accessed

The package operates on a single base table, IGS_AD_APTYP_PESTAT, accessed through its APPS synonym. This table stores the association rules linking admission application types to personal status types, along with a group number and a mandatory flag that determine whether the status is required, optional, or grouped during application processing. All INSERT_ROW, UPDATE_ROW, DELETE_ROW, and ADD_ROW operations target this table. The GET_FK_* routines conceptually reference the application type and personal status type definition tables to enforce referential integrity, though the metadata documents IGS_AD_APTYP_PESTAT as the sole directly referenced table.

Usage Notes

The package is referenced by two other packages within the IGS schema, indicating it participates in a broader admissions validation chain rather than being invoked directly by end users. Its primary consumers are the Oracle Forms-based Admissions setup screens, which call LOCK_ROW before edits, INSERT_ROW/UPDATE_ROW/DELETE_ROW on commit, and GET_PK_FOR_VALIDATION for duplicate checking. Concurrent programs and custom conversion scripts typically use ADD_ROW to load application type/personal status mappings from legacy or external sources while avoiding duplicate-key errors. During 12.1.1 to 12.2.2 upgrades, the package behaves consistently, as its API signature has remained stable; customizations should extend behavior by wrapping these procedures rather than modifying them, preserving supportability under the Online Patching model.