Search Results igs_az_advising_rels_pkg




Overview
Explore in AI Chat

Overview

The APPS.IGS_AZ_ADVISING_RELS_PKG package body is a PL/SQL API belonging to the Oracle E-Business Suite (EBS) Advanced Placement / Academic Advising module set within the Student Systems (IGS) product family. It encapsulates the business logic governing the relationship between students, advisors, and advising groups. Specifically, it manages rows in the IGS_AZ_ADVISING_RELS entity, which stores the associations linking a student to an advisor within a given advising group. The package follows the standard EBS "table handler" pattern, combining Data Manipulation Language (DML) operations with a set of validation helper functions used by Forms and other callers. Its object type is classified as OTHER under ETRM, meaning it is a delivered, supported object rather than an interface or concurrent-process driver. The body is documented as VALID, confirming it compiles cleanly against the APPS schema in the target environment. Dependencies include FND_API, FND_MESSAGE, FND_MSG_PUB, FND_GLOBAL, and APP_EXCEPTION, indicating that it uses the Oracle Application Object Library API error-handling and messaging framework rather than custom exception handling.

Key Procedures and Functions

The body exposes eleven documented procedures and functions:

  • INSERT_ROW — Inserts a new advising relationship record into the base table.
  • LOCK_ROW — Acquires a row-level lock to support concurrent-safe updates, typically invoked before modification in a Forms transaction.
  • UPDATE_ROW — Updates an existing advising relationship record.
  • ADD_ROW — Adds a row, generally wrapping insert logic with defaulting and validation.
  • DELETE_ROW — Removes an advising relationship record.
  • GET_PK_FOR_VALIDATION — Returns the primary key used in validation lookups.
  • GET_UK_FOR_VALIDATION — Returns the unique key used in validation lookups.
  • GET_FK_IGS_AZ_GROUPS — Retrieves the foreign key referencing the advising groups entity.
  • GET_FK_IGS_AZ_STUDENTS — Retrieves the foreign key referencing the students entity.
  • GET_FK_IGS_AZ_ADVISORS — Retrieves the foreign key referencing the advisors entity.
  • BEFORE_DML — A pre-DML hook that performs setup and defaulting (such as WHO-column population) before insert, update, or delete operations.

The three GET_FK_* functions and the primary/unique key functions support the standard Forms "WHEN-VALIDATE-RECORD" and LOV retrieval patterns.

Tables Accessed

The package reads and writes two documented tables via APPS synonyms: IGS_AZ_ADVISING_RELS (the base entity table holding active advising relationship records) and IGS_AZ_ADVISING_RELS_S (the corresponding sequence or shadow table used to generate unique identifiers). The base table stores the association between an advising group, a student, and an advisor, making it the central persistence point for this business object. The _S table supplies the surrogate primary key values consumed by INSERT_ROW and ADD_ROW. Foreign key resolution for the related IGS_AZ_GROUPS, IGS_AZ_STUDENTS, and IGS_AZ_ADVISORS entities is delegated through the GET_FK_* functions, which reference the corresponding packages IGS_AZ_GROUPS_PKG, IGS_AZ_STUDENTS_PKG, and IGS_AZ_ADVISORS_PKG.

Usage Notes

This package is normally invoked from the Academic Advising Forms (such as the advising relationship maintenance form) during record-level insert, update, and delete processing, where LOCK_ROW is called prior to modification to ensure transactional integrity. Validation routines are called on field and record validation triggers. The package is referenced by four other database objects, confirming its role as a shared dependency within the advising subsystem. It is not referenced by the standard concurrent manager submission path directly; instead it is called from Forms, other PL/SQL APIs, and custom code that must create or maintain advising relationships. Because it depends on FND_MSG_PUB and IGS_GE_MSG_STACK, callers should be prepared to inspect the message stack for error feedback rather than relying solely on raised exceptions. Typical customizations should call the public procedures rather than performing direct DML against IGS_AZ_ADVISING_RELS, so that WHO-column auditing, key generation, and validation logic remain consistent.