Search Results no_data_found_err




Overview
Explore in AI Chat

Overview

PA_COST_BASE_COST_CODES_PKG is a PL/SQL package in the APPS schema that supports the Oracle Projects cost base configuration model. Its single documented procedure, CHECK_UNIQUE, validates combinations of cost base attributes before they are stored in the PA_COST_BASE_COST_CODES table. The cost base is the foundation on which Oracle Projects builds burdening, costing, and revenue calculation logic: a cost base associates a cost base type with a cost plus structure and an indirect cost code, and each combination must be unique so that costing engines can deterministically resolve rates and amounts.

The package is classified as OTHER in the ETRM registry, reflecting its role as a low-level validation utility rather than a public business API. It carries the RCS revision marker PAXCICIB.pls 120.1 and has remained stable since 2005, indicating that the underlying uniqueness rule for cost base cost codes has not changed across releases. It references exactly one table, PA_COST_BASE_COST_CODES, and is not referenced by any other package, so its consumers are forms-based or direct callers rather than the cross-package dependency graph.

Key Procedures and Functions

  • CHECK_UNIQUE — Determines whether a candidate combination of cost plus structure, cost base, cost base type, and indirect cost code already exists in the cost base cost codes table. It accepts these four identifying attributes as input parameters and returns an OUT NOCOPY numeric status flag rather than raising an exception to the caller. The procedure begins by setting status to 0, then issues a SELECT against SYS.DUAL with a WHERE NOT EXISTS subquery over PA_COST_BASE_COST_CODES; when the subquery finds no matching row the query returns no rows, NO_DATA_FOUND is raised, and the handler assigns the symbolic constant NO_DATA_FOUND_ERR (value 100) to the status. Any other exception assigns SQLCODE. Callers therefore interpret status 0 as "duplicate exists" and status 100 as "combination is unique and safe to insert".

Tables Accessed

  • PA_COST_BASE_COST_CODES — The sole documented table, accessed read-only within CHECK_UNIQUE. The NOT EXISTS subquery filters on COST_BASE, COST_BASE_TYPE, COST_PLUS_STRUCTURE, and IND_COST_CODE, which are the columns that form the logical unique key for cost base cost code assignments. The procedure performs no inserts or updates; persistence is handled by the calling form or program after a successful uniqueness check.
  • SYS.DUAL — Used as the driving row source so that the EXISTS/NOT EXISTS result can be selected as a scalar value, enabling the NO_DATA_FOUND signaling mechanism.

Usage Notes

The package is typically invoked from Oracle Projects setup forms or from custom code that programmatically creates cost base cost codes. The conventional pattern is to call CHECK_UNIQUE before an INSERT and to raise a user-facing error such as "This cost base and indirect cost code combination already exists" when the returned status is 0. A status of 100 indicates the record is new; any other status value is a real database error and should be surfaced with the corresponding SQLCODE message. Because the procedure uses SELECT 1 INTO dummy rather than an explicit cursor count, callers must not treat a NO_DATA_FOUND exception as an application error — here it is the success signal, a design choice that has historically caused confusion in custom code that wraps the call in its own NO_DATA_FOUND handler.

The RCS header identifies the file as PLA/SQL (pls) with the "noship" flag, meaning it is not shipped as a standalone installable file but is deployed with the APPS code tree. In EBS 12.1.1 and 12.2.2 alike, the package is available under the APPS synonym namespace; any custom code should call APPS.PA_COST_BASE_COST_CODES_PKG.CHECK_UNIQUE directly rather than creating a local duplicate of the uniqueness logic, so that validation remains consistent with Oracle Projects' own setup validation. Since no other package references it, upgrades are unlikely to alter its signature, making it a relatively safe dependency for extensions, though it remains an internal object not covered by Oracle's public API commitment.