Search Results get_fk_igs_ps_ofr

Overview

IGS_PS_OFR_NOTE_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Student System (IGS) product family, which supports the academic and student administration functions of the institution. Specifically, this package manages the IGS_PS_OFR_NOTE entity, which associates free-text notes with course offerings. The "OFR" naming denotes Offerings, while "PS" denotes the Public Sector / Student System lineage of the module. The package provides the standard table-handling API pattern used throughout Oracle EBS for DML on a single base table, exposing insert, update, lock, delete and add operations alongside validation and foreign-key resolution helpers.

The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the calling user rather than the defining user. Its header identifies it as shipped code (the $Header line references IGSPI21S.pls, version 115.3, dated 2002/11/29), consistent with a long-established component of the Student System data model.

Key Procedures and Functions

The documented public interface comprises eleven procedures and functions:

• INSERT_ROW — Inserts a new offering note row into the base table. It accepts an in/out ROWID plus the identifying key columns (course code, reference number, calendar type, version number, course note type) and a mode parameter defaulting to 'R'.
• LOCK_ROW — Acquires a row-level lock on an existing note identified by its ROWID and key columns, supporting the standard optimistic locking sequence used by EBS forms.
• UPDATE_ROW — Updates an existing note row identified by ROWID and key columns, accepting the mode parameter.
• ADD_ROW — Adds a row, typically combining insert-or-update behavior with an in/out ROWID and the mode flag.
• DELETE_ROW — Deletes the note row identified by the supplied ROWID.
• GET_PK_FOR_VALIDATION — A function returning BOOLEAN that validates the primary key combination (course code, version number, calendar type, reference number) against the base table, used by forms to confirm that a given key exists.
• GET_FK_IGS_PS_NOTE_TYPE — Resolves and validates the foreign-key relationship to the note type reference entity, taking the course note type as input.
• GET_FK_IGS_PS_OFR — Resolves and validates the foreign-key relationship to the offering entity, taking course code, version number and calendar type. This is the procedure a user encounters when searching for "get_fk_igs_ps_ofr".
• GET_FK_IGS_GE_NOTE — Resolves and validates the foreign-key relationship to the general note entity, taking the reference number as input.
• CHECK_CONSTRAINTS — Accepts an optional column name and column value and performs constraint validation, used by form-level validation logic.
• BEFORE_DML — A pre-DML hook invoked internally by the other procedures, accepting an action plus the full set of key column values, to centralize validation and defaulting logic.

Tables Accessed

The package reads and writes the base table IGS_PS_OFR_NOTE, accessed through an APPS synonym. This table stores free-text notes attached to a specific course offering, keyed by course code, version number, calendar type and reference number. The foreign-key helper procedures additionally resolve and validate against related entities — the note type reference, the offering record, and the general note entity — in order to enforce referential integrity and surface meaningful validation errors to the caller.

Usage Notes

This package is a generated table-handling API typical of Oracle EBS, and is referenced by four other packages within the Student System. It is normally invoked indirectly: Oracle Forms in the Student System call the INSERT_ROW, UPDATE_ROW, LOCK_ROW and DELETE_ROW procedures during standard form transactions, while the GET_FK_* procedures and GET_PK_FOR_VALIDATION support LOV and key validation triggers. Custom concurrent programs or extensions that manipulate offering notes directly should call these documented procedures rather than performing direct DML, so that the BEFORE_DML validation and constraint checks are applied consistently. The CHECK_CONSTRAINTS procedure should be reserved for validation contexts where individual column values require testing.