Search Results chk_event_id

Overview

GHR_EVH_BUS is the business-rule layer of the GHR Event History table handler stack shipped with Oracle EBS HRMS (Oracle Human Resources) in releases 12.1.1 and 12.2.2. It belongs to the family of generated table handlers built on the Oracle Designer / HRMS table-handler template, in which every base table is wrapped by a shared layer (GHR_EVH_SHD), a business layer (GHR_EVH_BUS), and a data manipulation layer. The package encapsulates the validation logic that must run whenever a row of the GHR event history table is inserted, updated, or deleted, ensuring that primary-key integrity, object-version-number (row version) control, and mandatory-column checks are enforced consistently regardless of the calling interface.

The package body is structured as a private implementation unit: all entry points are declared in the matching specification, while helper routines such as the primary-key checker remain internal to the body. As the excerpted source shows, the body defines a private global package-name constant, declares an internal PK-validation procedure (chk_event_history_id, referenced in older documentation and in the user's search term chk_event_id), and calls the shared layer to determine whether the current operation is an insert or an update. The ETRM classification for this object is OTHER, reflecting that it is an internal supporting handler rather than a public, standalone business API.

Key Procedures and Functions

The documented public procedures are the three standard table-handler validation entry points:

• INSERT_VALIDATE — Invoked before a new event-history row is written. It performs insert-time validation, including confirmation that the primary key is null on insert (the key is expected to be populated by the sequence or by the caller's key-generation logic) and that all mandatory attributes are supplied.
• UPDATE_VALIDATE — Invoked before an existing event-history row is modified. It verifies that the primary key has not been altered by the update and that the object version number carried by the caller matches the stored value, providing optimistic locking against concurrent modification.
• DELETE_VALIDATE — Invoked before a row is removed. It confirms that the row exists and is in a state that permits deletion, protecting referential integrity for dependent records.

Internally, the body also contains chk_event_history_id, the procedure described in the source excerpt. It calls GHR_EVH_SHD.api_updating to establish whether the operation is an update; if so, and if the incoming key differs from the stored key in GHR_EVH_SHD.g_old_rec, it raises a constraint error naming the GHR_EVENT_HISTORY_PK constraint. If not an update, it checks whether the key is null, which is the correct state for an insert. Errors are surfaced through the shared layer's constraint_error routine.

Tables Accessed

The package operates against the GHR event history entity through its APPS synonym GHR_EVENTS, as recorded in the ETRM metadata. The business layer itself does not issue DML directly; instead it delegates persistence to the shared/data layers and reads the cached old-record image (g_old_rec) from GHR_EVH_SHD to compare pre- and post-update values. Access is therefore primarily a read of the current and prior row state for validation, with the actual insert, update, and delete statements executed by the downstream handler after INSERT_VALIDATE, UPDATE_VALIDATE, or DELETE_VALIDATE completes successfully.

Usage Notes

GHR_EVH_BUS is not intended to be called directly by end users. It is invoked in three conventional ways. First, Oracle Forms-based HRMS windows that maintain event-history data call the table handler chain on save, so that validation occurs within the form's transaction before commit. Second, the package is referenced by three other packages (per ETRM), which typically include the corresponding process or event-management APIs that write event history rows as a side effect of business transactions. Third, concurrent programs and custom PL/SQL extensions that insert or maintain event-history records are expected to route through the business layer rather than performing direct DML, so that version checking and key integrity rules are preserved.

Because the GHR_EVH_BUS body is a generated artifact whose header dates from the 11i era, customers should avoid modifying it; the supported extension pattern is to wrap or precede it with custom validation. Any localized change risks being overwritten by an HRMS patch or a regenerated table handler during upgrade between 12.1.1 and 12.2.2.