Search Results igs_az_students_s




Overview

The APPS.IGS_AZ_STUDENTS_PKG package body is a PL/SQL database object within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 releases, owned by the APPS schema and registered with a status of VALID. It belongs to the student system product family (the IGS and IGS_AZ object prefixes) and functions as the primary table handler for the IGS_AZ_STUDENTS entity, which stores student records within that subsystem.

The package exposes a DML-oriented API classified as "OTHER" rather than a full public business API. Its purpose is to centralise the insert, update, delete, locking, and validation logic applied to student rows, so that concurrent programs, forms, and dependent PL/SQL units do not each re-implement that logic. The body depends on shared infrastructure packages including FND_API, FND_GLOBAL, FND_MESSAGE, FND_MSG_PUB, APP_EXCEPTION, and IGS_GE_MSG_STACK, indicating that it participates in the standard EBS error-handling and message-stack model. It also depends on IGS_AZ_ADVISING_RELS_PKG, IGS_AZ_GROUPS_PKG, and IGS_AZ_GEN_001, confirming it is an integrated component of the IGS_AZ advising and student-grouping functionality.

Key Procedures and Functions

The ETRM metadata documents nine procedures/functions in this package body:

  • INSERT_ROW — Inserts a new row into the base student table, applying the package's standard column defaults and any derived values.
  • LOCK_ROW — Obtains a row-level lock on an existing student record, typically as a prerequisite to a controlled update or delete.
  • UPDATE_ROW — Updates an existing student record in the base table.
  • ADD_ROW — Provides the higher-level "add" entry point, orchestrating the insert path together with associated validation and message handling.
  • DELETE_ROW — Removes a student record from the base table.
  • GET_PK_FOR_VALIDATION — Resolves and returns the primary key value used to validate a candidate row.
  • GET_UK_FOR_VALIDATION — Resolves and returns the unique key value used to validate a candidate row.
  • GET_FK_IGS_AZ_GROUPS — Returns the foreign key value linking the student record to the IGS_AZ_GROUPS entity.
  • BEFORE_DML — A pre-DML hook invoked before insert, update, or delete processing to enforce consistency and prepare data.

Parameter lists are intentionally omitted; the procedures are described solely by their documented purpose.

Tables Accessed

The package reads and writes two tables, reached through APPS synonyms:

  • IGS_AZ_STUDENTS — The base (transaction) table holding the student records. All DML in this package, including INSERT_ROW, UPDATE_ROW, DELETE_ROW, and LOCK_ROW, targets this table.
  • IGS_AZ_STUDENTS_S — The corresponding translation (TL) table, which stores language-specific descriptive attributes for each student row. This table is populated and maintained alongside the base table and is the object most closely associated with the user's search term "igs_az_students_s".

The foreign-key accessor GET_FK_IGS_AZ_GROUPS reflects the relationship between the student records and the IGS_AZ_GROUPS entity handled by IGS_AZ_GROUPS_PKG.

Usage Notes

Because IGS_AZ_STUDENTS_PKG is not referenced by any other database object, it is a top-level entry point rather than an internal helper. It is invoked directly from Oracle Forms-based maintenance screens for the IGS_AZ student entity, from concurrent programs that load or amend student data, and from custom extensions that need to insert or modify student rows while respecting the package's validation and error-handling rules.

Callers should treat INSERT_ROW, UPDATE_ROW, and DELETE_ROW as the low-level primitives, and ADD_ROW plus BEFORE_DML as the controlled path that also performs validation and populates the FND message stack. The presence of FND_MSG_PUB and IGS_GE_MSG_STACK dependencies implies that errors raised during processing are registered on the standard message stack, so callers should check the stack after invocation rather than relying solely on exceptions. All work should be performed in the APPS schema context, since dependencies are resolved through APPS synonyms and grants.