Search Results csi_iea_values_s




Overview

APPS.CSI_IEA_VALUES_PKG is the PL/SQL package body that encapsulates the DML logic for the CSI_IEA_VALUES entity within the Oracle E-Business Suite Install Base (CSI) application. The "IEA" designation refers to Installed Base Extension Attributes, the extensible attribute framework that allows customers to capture additional descriptive or transactional data against installed base instances beyond the seeded attribute set. The package functions as the designated programmatic gateway for creating, maintaining, and removing rows in the CSI_IEA_VALUES table, shielding calling code from direct manipulation of the underlying schema objects.

The package body is documented as VALID under the APPS schema and is classified as "OTHER" in the ETRM metadata, indicating that it is an internal utility package rather than a public, published API such as those that expose a formal FND_API-based interface contract. It is, however, a critical dependency within the Install Base data model, and the metadata records that it is referenced by one other database object, confirming that it participates in a shared call chain within the application.

Key Procedures and Functions

The ETRM documentation records four documented procedures in the package body, each responsible for a discrete data manipulation operation:

  • INSERT_ROW — Creates a new row in the CSI_IEA_VALUES table, populating the attribute value record for the associated installed base entity. It is the entry point used when a new extension attribute value must be captured.
  • UPDATE_ROW — Modifies an existing CSI_IEA_VALUES row, applying changes to previously stored attribute values while preserving the record's identity and key relationships.
  • LOCK_ROW — Obtains a row-level lock on a CSI_IEA_VALUES record. This is typically invoked prior to an update to guarantee concurrency control and to prevent lost updates when multiple sessions interact with the same installed base attribute record.
  • DELETE_ROW — Removes a CSI_IEA_VALUES row from the table, allowing extension attribute data associated with an installed base entity to be retired.

Parameter lists are not enumerated in the available metadata and are therefore not reproduced here. The locking procedure follows the conventional Oracle Forms server-side pattern of pairing an explicit LOCK_ROW call with the UPDATE_ROW operation.

Tables Accessed

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

  • CSI_IEA_VALUES — The base table storing extension attribute values for installed base records. It is the primary target of the INSERT_ROW, UPDATE_ROW, and DELETE_ROW operations and the subject of the row lock acquired by LOCK_ROW.
  • CSI_IEA_VALUES_S — The corresponding sequence used to generate unique identifiers, typically the primary key, for new rows inserted into CSI_IEA_VALUES. This object is also the likely source of the search term "csi_iea_values_s" that led to this package.

In addition to these tables, the metadata lists DUAL and the STANDARD package in the SYS schema as dependencies, along with the APPS packages APP_EXCEPTION, FND_API, and FND_MESSAGE. These references confirm that the package uses the standard EBS error-handling and message-resolution infrastructure, raising and translating errors through FND_MESSAGE and APP_EXCEPTION while conforming to the FND_API conventions.

Usage Notes

CSI_IEA_VALUES_PKG is an internal, backend package. It is not a user-facing API and does not appear in the Oracle Integration Repository as a published web service. It is most commonly invoked from Oracle Forms-based maintenance screens in the Install Base module, and from any PL/SQL code that needs to manipulate extension attribute values on installed base instances rather than writing directly to CSI_IEA_VALUES.

Because the metadata records that the package is referenced by one other PL/SQL object and references CSI_IEA_VALUES_S, modification or extension of this package requires review of the dependent object to prevent compilation or behavioral regressions. Customizations should preserve the existing procedure signatures and the FND_API-based error handling contract. Redefinition of this package body in a custom schema is not recommended; the supported approach is to call the APPS-owned procedures as documented.