Search Results get_fk_igs_ca_inst

Overview

IGS_EN_SVS_AUTH_CAL_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Student System (IGS) product family, specifically the SEVIS authorization functionality within the Enrollment module. SEVIS (Student and Exchange Visitor Information System) is the United States government database used to track international students and exchange visitors. In EBS, the IGS_EN_SVS_AUTH and IGS_EN_SVS_AUTH_CAL tables store SEVIS authorization records and the academic calendar instances to which those authorizations apply. This package provides the standard table-handling application programming interface (API) for the IGS_EN_SVS_AUTH_CAL intersection table, enabling insert, lock, delete, primary-key validation, and foreign-key validation operations. It is classified as OTHER in the ETRM registry and is referenced by two other packages, indicating its role as a dependent utility package rather than a standalone business process driver. The header comment (revision 120.0, dated 2006) indicates the package has been stable across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The package exposes seven documented procedures and functions, each performing a discrete DML or validation task:

• INSERT_ROW — Inserts a new authorization-to-calendar association row, accepting a ROWID out parameter, the SEVIS authorization identifier, calendar type, calendar instance sequence number, and an optional mode flag (default 'R').
• LOCK_ROW — Obtains a row-level lock on an existing record using its ROWID together with the key columns, protecting the row from concurrent modification.
• DELETE_ROW — Deletes an existing association row identified by its ROWID.
• GET_PK_FOR_VALIDATION — Returns a Boolean indicating whether the supplied primary key combination (authorization ID, calendar type, and sequence number) exists; used as a primary-key lookup for validation.
• GET_FK_IGS_EN_SVS_AUTH — Validates that the supplied SEVIS authorization ID exists in the parent IGS_EN_SVS_AUTH table, effectively a foreign-key check against the authorization header.
• GET_FK_IGS_CA_INST — Validates that the supplied calendar type and calendar instance sequence number exist in the calendar instance table, providing the foreign-key check requested by the "get_fk_igs_ca_inst" search term.
• BEFORE_DML — A shared pre-DML hook invoked internally to apply WHO-column auditing (creation date, created by, last update date, last updated by, last update login) and to enforce business rules prior to insert, update, or delete.

Tables Accessed

The package reads from and writes to the IGS_EN_SVS_AUTH_CAL table, the intersection entity holding SEVIS authorization to calendar-instance mappings. It validates against IGS_EN_SVS_AUTH, the parent authorization record, and against the calendar instance data referenced by GET_FK_IGS_CA_INST. The ETRM metadata additionally lists HZ_PARTIES and IGS_EN_ELGB_OVR_STEP as referenced via APPS synonyms; HZ_PARTIES supplies party (person/organization) context for the student or exchange visitor, while IGS_EN_ELGB_OVR_STEP supports eligibility override step logic that may inform authorization processing.

Usage Notes

This package is typically invoked indirectly. Oracle Forms-based SEVIS authorization maintenance screens and any concurrent programs that create or maintain SEVIS authorizations call the insert, lock, and delete routines rather than performing direct DML against IGS_EN_SVS_AUTH_CAL. The validation functions (GET_PK_FOR_VALIDATION, GET_FK_IGS_EN_SVS_AUTH, GET_FK_IGS_CA_INST) are commonly called from Forms validation triggers and from other PL/SQL packages — consistent with the two packages documented as referencing this one. Because the API classification is OTHER, the package is not part of the public, officially supported API surface, and customizations should call it defensively. Direct DML against the underlying table should be avoided so that WHO audit columns and foreign-key integrity are preserved. When upgrading between 12.1.1 and 12.2.2, no signature changes are documented, so dependent custom code should remain compatible.