Search Results fnd_conc_rel_disj_members




Overview
Explore in AI Chat

Overview

The table FND_CONC_REL_DISJ_MEMBERS is a core data object within the Oracle E-Business Suite (EBS) Application Object Library (FND) module. It functions as a junction table that defines the constituent elements, or members, of a disjunction in the context of Concurrent Processing release rules. Release rules are complex logical conditions that determine when a concurrent request is eligible to run based on the status of other requests. A disjunction represents an "OR" condition within a release rule's logic. This table stores the specific periods or states, which are the fundamental conditions, that are linked together by the disjunction. Its role is critical for the advanced scheduling and dependency management capabilities of the Concurrent Manager in both EBS 12.1.1 and 12.2.2.

Key Information Stored

The table's structure is designed to link a disjunction to its component conditions. The primary key is a composite of columns that uniquely identify a member within a specific disjunction. Key columns include DISJUNCTION_APPLICATION_ID and DISJUNCTION_ID, which together reference the parent disjunction defined in FND_CONC_RELEASE_DISJS. The PERIOD_OR_STATE_FLAG indicates whether the member is a period or a state condition. Depending on this flag's value, either the STATE_APPLICATION_ID and STATE_ID columns (referencing FND_CONC_RELEASE_STATES) or the PERIOD_APPLICATION_ID and PERIOD_ID columns (referencing FND_CONC_RELEASE_PERIODS) will be populated to define the specific condition. The NEGATION_FLAG allows for the logical negation (a "NOT" condition) of the linked period or state. Standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) are also present for auditing.

Common Use Cases and Queries

This table is primarily accessed for troubleshooting and analyzing complex release rule logic. A common scenario involves diagnosing why a concurrent request is held in a "Pending" status. An administrator can trace from the request's release rule, through its disjunctions, to the specific state or period conditions that are not being met. A typical diagnostic query would join this table to its parent and child reference tables to decode the rule's logic.

  • Sample Query to List Disjunction Members:
    SELECT drd.disjunction_name,
    m.period_or_state_flag,
    m.negation_flag,
    crs.state_code,
    crp.period_name
    FROM fnd_conc_rel_disj_members m,
    fnd_conc_release_disjs drd,
    fnd_conc_release_states crs,
    fnd_conc_release_periods crp
    WHERE m.disjunction_application_id = drd.application_id
    AND m.disjunction_id = drd.disjunction_id
    AND crs.application_id (+) = m.state_application_id
    AND crs.state_id (+) = m.state_id
    AND crp.application_id (+) = m.period_application_id
    AND crp.period_id (+) = m.period_id
    AND drd.disjunction_name = '&DISJUNCTION_NAME';

Related Objects

FND_CONC_REL_DISJ_MEMBERS sits at the center of a key relationship hierarchy for release rules. It is a child table of FND_CONC_RELEASE_DISJS, which defines the disjunction header. It is also a child table, via foreign key relationships, to FND_CONC_RELEASE_STATES and FND_CONC_RELEASE_PERIODS, which define the atomic conditions. The table maintains standard foreign keys to FND_USER and FND_LOGINS for WHO column data. This table is referenced by the underlying Concurrent Manager engine and is integral to the views and APIs that manage and report on concurrent program dependencies, though direct application-tier programming against this table is uncommon.