Search Results enable_disabled_primary_keys




Overview
Explore in AI Chat

Overview

FND_OAM_DSCFG_PROC_LIBRARY_PKG is an Oracle EBS Applications (APPS) package that supports the Diagnostic Configuration (DSCFG) engine used by Oracle Applications Manager (OAM). The package is declared with AUTHID CURRENT_USER, meaning its SQL executes under the privileges of the invoking schema rather than the defining schema. Its core business function is to temporarily suspend schema-level constraints and triggers on target application tables so that the DSCFG processing engine can modify those tables without interference. Each suppressed database object is registered as a DSCFG_OBJECT record, forming an audit trail that allows a companion procedure to restore the original state afterward. In effect, the package provides a controlled, reversible mechanism for disabling and re-enabling triggers and primary keys during diagnostic configuration operations, keeping the database consistent once the engine completes its work.

Key Procedures and Functions

The package exposes four documented procedures, organized as two disable/re-enable pairs:

  • DISABLE_TARGET_TABLES_TRIGGERS — Disables every trigger defined on the tables that the engine is about to modify. For each disabled trigger, a new DSCFG_OBJECT record is created identifying that trigger, so the reverse operation can undo the change. The configuration instance identifier is not passed as a parameter; it is read from INSTANCES_PKG state.
  • RE_ENABLE_DISABLED_TRIGGERS — The companion procedure that re-enables the triggers previously disabled by DISABLE_TARGET_TABLES_TRIGGERS, using the DSCFG_OBJECT records to determine which triggers to restore.
  • DISABLE_TARGET_PRIMARY_KEYS — Disables all primary keys on tables that will be modified by the engine. As with triggers, each disabled primary key generates a DSCFG_OBJECT record identifying it for later restoration.
  • ENABLE_DISABLED_PRIMARY_KEYS — The companion procedure that re-enables the primary keys previously disabled, again driven by the recorded DSCFG_OBJECT entries.

All four procedures operate without explicit parameters. Consistent with the package header comments, they should only be invoked after a configuration instance has been created or set, since the configuration instance ID is retrieved from INSTANCES_PKG state. None of the procedures return a status value; instead, failures are written to the ERRORS_FOUND_FLAG and MESSAGE attributes of the affected objects.

Tables Accessed

The package interacts with several data sources and dictionary views through APPS synonyms:

  • FND_OAM_DSCFG_OBJECTS — The registry of diagnostic configuration objects. The package inserts records here to identify each disabled trigger or primary key, and reads them back when re-enabling, forming the state ledger for the disable/restore cycle.
  • DBA_TRIGGERS — The data dictionary view used to identify the triggers currently defined on target tables so they can be disabled and later restored.
  • DBMS_SQL — The dynamic SQL facility used to issue the actual ALTER statements that disable and enable triggers and primary keys at runtime.
  • PLITBLM — Referenced internally in support of the package's operations.

Usage Notes

This package is not a general-purpose public API; it is an internal library called by the Diagnostic Configuration engine rather than directly by end users. It is typically invoked during DSCFG processing initiated from Oracle Applications Manager, when the engine must temporarily relax schema constraints on the tables it intends to alter. Because the procedures derive the configuration instance from INSTANCES_PKG state, they must not be called in isolation—a configuration instance must have been created or set first. The AUTHID CURRENT_USER declaration means the invoking user must hold sufficient privileges to alter the affected tables. The design is intentionally transactional and reversible: disable and re-enable operations are paired, and every suppressed trigger or primary key is recorded in FND_OAM_DSCFG_OBJECTS so that no object is left disabled after processing. Custom code should avoid invoking these procedures outside the engine's normal lifecycle, as improper sequencing could leave target tables without their triggers or primary keys.