Search Results child_flag

Overview

APPLSYS.FND_CHILD_ANNOTATIONS is a child table within the Oracle E-Business Suite Integration Repository, the metadata framework that catalogues published interface definitions, service operations, and their associated annotations. The table stores child-level annotations belonging to parent integration-repository entities, most commonly interface definitions and their subordinate elements. It is owned by the APPLSYS schema and belongs to the FND - Application Object Library product family. In Oracle EBS 12.1.1 and 12.2.2, the object is delivered as a VALID, dictionary-managed repository table.

The metadata classifies this object heuristically as standalone within a Data Vault style model. In practice, this means FND_CHILD_ANNOTATIONS functions as a reference or relationship table without a documented foreign-key dependency on another repository object. Because the Integration Repository is application metadata rather than transactional data, this table should not be interpreted as a conventional hub or satellite; it is best treated as a descriptive metadata store keyed by parent annotations.

Key Information Stored

The documented physical schema for ETRM 12.2.2 lists six columns in the APPLSYS owner schema:

• PARENT_ID — Identifies the parent annotation or repository entity to which the child annotation belongs. This is the primary join column used when tracing child annotations back to their owning definition.
• PARENT_ID2 — A secondary parent identifier, used within the unique business key to distinguish annotation records that share the same PARENT_ID and annotation value.
• PARENT_FLAG — A flag qualifying the parent context of the annotation; part of the composite primary key.
• CHILD_FLAG — A flag qualifying the child context of the annotation; also part of the composite primary key.
• ANNOTATION_VALUE — The actual annotation text or value carried by the child record. This is the principal payload column and the most frequently queried attribute.
• ZD_EDITION_NAME — The edition name used by Edition-Based Redefinition (EBR). This column is significant in EBS 12.2.2, where EBR enables online patching; it must be included in queries executed against the editioned view of the table.

The primary key is FND_CHILD_ANNOTATIONS_PK, defined over (CHILD_FLAG, PARENT_FLAG, PARENT_ID). The unique index FND_CHILD_ANNOTATIONS_U1, defined over (PARENT_ID, ANNOTATION_VALUE, PARENT_ID2, ZD_EDITION_NAME), is the documented business-key candidate and provides the principal access path for lookups by parent identifier.

Common Use Cases and Queries

The most frequent scenario is retrieving all annotations for a known parent entity. A representative query pattern is:

• SELECT child.PARENT_ID, child.PARENT_ID2, child.ANNOTATION_VALUE, child.CHILD_FLAG, child.PARENT_FLAG FROM apps.fnd_child_annotations child WHERE child.PARENT_ID = :parent_id;
• Diagnostic joins between parent and child annotation rows on (PARENT_ID, PARENT_ID2) to reconcile annotation hierarchies in a custom integration repository report.
• Extraction of annotation text for documentation or migration projects, filtering on ANNOTATION_VALUE IS NOT NULL.

In EBS 12.2.2 environments, queries must respect the editioned view. Accessing the table through the APPS synonym against the run edition, or explicitly filtering on ZD_EDITION_NAME, avoids duplicate or stale rows returned when multiple editions are present. The Integration Repository is populated by Oracle during product installation and by patching; direct DML against this table is not supported and should be performed only through Oracle-supplied repository utilities.

Related Objects

• FND_ANNOTATIONS — Parent annotation table supplying the PARENT_ID values referenced here.
• FND_CHILD_OBJECTS — Stores child object definitions associated with repository annotations.
• FND_IREP_CHILDREN — Integration repository child relationship definitions.
• FND_IREP_ANNOTATIONS/FND_IREP_ANNOTATION_VALUES — Repository annotation header and value tables.
• FND_HIGH / FND_IREP_CLASSES — Parent repository classification tables used to group annotations.

Because the table is classified as standalone, dependencies are logical rather than enforced by database constraints; joins should be validated against the Integration Repository data model for the specific EBS release.