Search Results csi_transactions_s




Overview
Explore in AI Chat

Overview

APPS.CSI_TRANSACTIONS_PKG is a stored PL/SQL package body in the Oracle E-Business Suite Applications schema (APPS). It belongs to the CSI (Install Base / Customer Service Intelligence) product family and provides the core transactional data manipulation logic for the CSI_TRANSACTIONS entity, which stores transaction records associated with installed base instances and their lifecycle events. The package is classified as an OTHER API, indicating it is primarily intended as an internal implementation unit rather than a public, FND_API-compliant interface; however, it is referenced by two other database objects, confirming it forms part of a shared internal dependency chain within the Install Base module.

The object carries a status of VALID in both Oracle EBS 12.1.1 and 12.2.2, and its package body depends on the CSI_TRANSACTIONS_PKG specification, the CSI_TRANSACTIONS table, the CSI_TRANSACTIONS_S sequence, the FND_API utility package, and standard SYS constructs such as DUAL and STANDARD. This dependency footprint is characteristic of a base-table maintenance package that handles surrogate key generation, row-level persistence, and concurrency control for the underlying Install Base transaction table.

Key Procedures and Functions

Three documented procedures constitute the public surface of this package:

  • INSERT_ROW — Creates a new record in the CSI_TRANSACTIONS table. It is responsible for populating the primary key (typically sourced from the CSI_TRANSACTIONS_S sequence), applying WHO-column auditing attributes, and enforcing the mandatory column set defined by the table.
  • UPDATE_ROW — Modifies an existing CSI_TRANSACTIONS record. It updates the mutable columns of the row while preserving the primary key and creation audit information, and it applies the standard WHO-column update attributes.
  • LOCK_ROW — Acquires a row-level lock on a specified CSI_TRANSACTIONS record, normally via a SELECT ... FOR UPDATE construct. This procedure is used to serialize concurrent modifications and prevent lost updates when multiple sessions attempt to change the same transaction row.

No function members are documented. Parameter lists are not exposed in the available metadata and should be confirmed by inspecting the package specification in the target environment.

Tables Accessed

The package operates against two documented database objects, both accessed through APPS synonyms:

  • CSI_TRANSACTIONS — The primary base table. It holds the transaction rows that INSERT_ROW, UPDATE_ROW, and LOCK_ROW manipulate. This is the sole write target of the package.
  • CSI_TRANSACTIONS_S — The sequence used to generate unique primary key values for newly inserted transaction rows. Reading this sequence is what enables INSERT_ROW to assign a surrogate key without relying on database triggers.

The dependency listing also shows FND_API, which suggests the package may use Oracle Application Object Library utilities for message handling, error stacking, or savepoint management during transaction processing.

Usage Notes

CSI_TRANSACTIONS_PKG is an internal package invoked indirectly by higher-level Install Base APIs and concurrent programs rather than being called directly from Oracle Forms or user-facing UI. Because it is classified as OTHER and its procedures are low-level row handlers (insert, update, lock), it is typically consumed by wrapper packages that impose business validation, security, and WHO-column defaults before delegating persistence to this package.

Custom extensions should treat this package as a private implementation detail. Direct invocation is discouraged; instead, developers should call the documented Install Base public APIs, which in turn depend on CSI_TRANSACTIONS_PKG. Any customization must respect the sequence-based key generation on CSI_TRANSACTIONS_S and perform an explicit LOCK_ROW call before UPDATE_ROW when concurrent modification of the same transaction is possible. The package is not referenced by any database object according to the metadata, confirming it sits at a leaf of the dependency graph for its write path.