Search Results g_no_error

Overview

DELETE_FROM_IREP is an Oracle Application Object Library (FND) utility package owned by APPS in the Oracle E-Business Suite. Its documented purpose is to remove entries associated with the Oracle EBS Integrated Repository (IREP) infrastructure. IREP is the metadata repository that stores the definitions of extended functionality objects, including integrated SOA Gateway service mappings, class definitions, data source assignments, function flavors, and the relationships that link forms, functions, and underlying tables. The package provides a controlled mechanism for purging these repository entries so that stale or unwanted registrations do not remain in the metadata tables and continue to participate in repository-driven processing.

The package is declared with AUTHID CURRENT_USER, meaning its procedures execute with the privileges of the calling user rather than with the definer's privileges. Callers must therefore hold the appropriate grants on the FND tables it manipulates. Source header information indicates a version dated July 2012 (120.1.12020000.5), consistent with the 12.1.1 and 12.2.2 codelines.

Key Procedures and Functions

The documented package exposes a single procedure. Two package-level constants, G_NO_ERROR and G_WARNING, define status values that indicate success without error and a generic warning condition respectively; these are not procedures and are used to communicate execution outcome.

• DELETE_IREP_ENTRY — the sole documented procedure. It accepts a single numeric parameter, key_id, which identifies the repository entry to be removed. Invoking the procedure deletes the specified IREP record and the dependent metadata rows associated with that key. The key-based signature indicates that callers must first resolve the identifier of the target entry, typically from the repository class or object key set tables, before invoking the delete.

The ETRM classification for this API is OTHER, reflecting that it is an internal utility rather than a public, supported integration interface.

Tables Accessed

The package operates across a wide set of FND repository tables reachable through APPS synonyms. These fall into several functional groups:

• IREP class definitions: FND_IREP_CLASSES and FND_IREP_CLASSES_TL store the base and translated class metadata. FND_IREP_CLASS_DATASOURCES and FND_IREP_CLASS_PARENT_ASSIGNS hold data source bindings and parent-child class relationships.
• IREP usage and mapping: FND_IREP_USES_MAPS and FND_IREP_USES_TABLES record the mapping and table usage entries linked to a class. FND_IREP_FUNCTION_FLAVORS captures function flavor registrations, and FND_IREP_DEFERRED_LOAD_FILES tracks deferred load artifacts.
• Forms, functions, and objects: FND_FORM_FUNCTIONS, FND_FORM_FUNCTIONS_TL, FND_OBJECTS, FND_OBJECTS_TL, FND_OBJECT_KEY_SETS, and FND_CHILD_ANNOTATIONS describe the forms functions, repository objects, key sets, and annotations that IREP entries reference.
• Supporting definitions: FND_LOOKUP_ASSIGNMENTS links repository entries to lookup values.

Deleting an entry requires coordinated removal or validation across these tables to prevent orphaned mappings between repository classes, objects, and their underlying database objects.

Usage Notes

DELETE_FROM_IREP is an internal maintenance utility and is not referenced by any other packaged API, as indicated by the zero-reference count in the ETRM metadata. It is typically invoked during administration or development activities when an incorrect or obsolete Integrated Repository registration must be withdrawn — for example, when reversing a mistaken Integrated SOA Gateway service or class setup. Invocation may occur from an administrative form, a concurrent program, or custom PL/SQL that resolves the target key_id and calls DELETE_IREP_ENTRY.

Because the package is classified as OTHER and is not documented as a supported public API, it should be used with caution. Callers should confirm the exact repository entry identified by the key, ensure no dependent repository definitions remain active, and back up affected metadata before deletion. Because execution is under AUTHID CURRENT_USER, the invoking session must have sufficient privileges on the FND repository tables.