Search Results check_session_overlap




Overview
Explore in AI Chat

Overview

APPS.OTA_EVENT_SWI is the server-side wrapper package for the Oracle E-Business Suite Training Administration (OTA) event business object. The name suffix "SWI" denotes "Small Wrapper Interface," a naming convention Oracle's OTA and OTA-adjacent modules use for packages that encapsulate row-level operations against the OTA_EVENTS entity. Its purpose is to expose controlled, validated entry points for creating, updating, and deleting training events, updating event enrollment records, and detecting scheduling conflicts between sessions. The package header was last stamped for release 12.1 (version 120.4.12010000.2) in 2009 and is carried forward unchanged into the 12.2.2 reference environment.

The package is classified as OTHER in the ETRM metadata, meaning it is neither a formally published public API nor purely internal. It is callable from hosting forms, concurrent processing, and integration code, but it is not the primary documented interface for the event entity. No other package in the EBS inventory is recorded as referencing it.

Key Procedures and Functions

Six procedures are documented for this package:

  • CREATE_EVENT — Inserts a new training event into OTA_EVENTS. The signature accepts the effective date, event identifier, business group, owning organization, event type, title, and a broad set of optional scheduling, financial, and enrollment attributes. It returns the newly assigned object version number, which the caller must retain for subsequent updates.
  • UPDATE_EVENT — Modifies an existing event record. It operates on the same attribute set as CREATE_EVENT and performs the standard optimistic-locking check against the object version number.
  • UPD2_UPDATE_EVENT — A secondary update routine, retained for compatibility with an earlier or alternate attribute profile. Its continued presence alongside UPDATE_EVENT reflects the layered evolution of the OTA schema rather than a distinct business function.
  • DELETE_EVENT — Removes an event and its dependent records. This is the destructive counterpart to CREATE_EVENT and is normally invoked only when no active enrollments or sessions remain.
  • UPDATE_ENROLLMENT — Adjusts enrollment-related data attached to an event, allowing attendance figures and enrollment state to be maintained without rewriting the entire event row.
  • CHECK_SESSION_OVERLAP — Validates that proposed session timings for an event do not conflict with sessions already scheduled. This is the routine most frequently located by the search term "check_session_overlap," and it is the package's principal business-rule guard.

Tables Accessed

The metadata records three referenced objects, resolved through APPS synonyms:

  • OTA_EVENTS — The primary entity table. All insert, update, and delete operations target this table, and CHECK_SESSION_OVERLAP reads existing session data associated with event rows.
  • HR_ALL_ORGANIZATION_UNITS — Read to validate or resolve the organization and business group context supplied by the caller, ensuring the event is attributed to a valid HR organization.
  • DUAL — Used for scalar evaluations, typically default value resolution and prerequisite checks within the wrapper logic.

Usage Notes

The package is normally invoked indirectly. The OTA event maintenance forms call these wrappers rather than issuing DML directly, which keeps validation and object-version handling centralized. Concurrent programs that generate or roll up training events, and custom PL/SQL integrations loading event data from external learning systems, call the procedures directly from the APPS schema.

Two practical constraints apply. First, always capture the object version number returned by CREATE_EVENT and pass it back on UPDATE_EVENT; failing to do so will raise a row-locking error. Second, invoke CHECK_SESSION_OVERLAP before committing any session or event date change, because the underlying OTA tables do not enforce overlap rules at the database level. Because the package is not a registered public API, Oracle support treats its signature as subject to change between patch levels, so custom code should wrap it defensively.