Results for “effective_date”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

FND_SESSIONS is a core Application Object Library (FND) table owned by the APPLSYS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented description identifies it as the repository of current sessions of Oracle Application Object Library — that is, the active runtime session registry for the EBS application tier. Each row represents a session established by a user, a concurrent program, or an internal framework process, and the table therefore underpins session tracking, cleanup, and audit-style reporting across the EBS instance.

The ETRM metadata classifies FND_SESSIONS heuristically as hub-leaning within a Data Vault modeling approach. In that reading, SESSION_ID behaves as a hub business key, uniquely identifying each session independently of its descriptive attributes, while dependencies such as the relationship to FND_CONCURRENT_PROCESSES act as links. This classification is a modeling suggestion derived from the foreign key topology, not a statement about how Oracle physically implemented the table.

Key Information Stored

The documented physical schema for 12.2.2 is deliberately narrow, comprising only two columns. This brevity reflects the table's role as a lightweight session registry rather than a descriptive master.

• SESSION_ID — The surrogate primary key, enforced by FND_SESSIONS_PK. It uniquely identifies each Application Object Library session and is the column referenced by dependent objects.
• EFFECTIVE_DATE — The date associated with the session record, forming the second component of the unique index FND_SESSIONS_U1 (SESSION_ID, EFFECTIVE_DATE).

The unique index FND_SESSIONS_U1 is the documented business-key candidate: the combination of SESSION_ID and EFFECTIVE_DATE guarantees uniqueness at the granularity of a session per effective date. This distinction matters when writing joins, since a plain SESSION_ID predicate may be insufficient if multiple effective-date rows are retained. Users of earlier or customized environments should verify the actual column list in their instance, as the metadata documents only these two columns.

Common Use Cases and Queries

The principal practical value of FND_SESSIONS is as the parent of concurrent processing activity. Administrators and developers join it to FND_CONCURRENT_PROCESSES to attribute a running or completed concurrent request to the session that spawned it, which is useful for diagnosing runaway requests, tracing who initiated a job, and reconciling session counts against system profiles.

• Session-to-request tracing: SELECT s.SESSION_ID, c.CONCURRENT_REQUEST_ID FROM APPLSYS.FND_SESSIONS s, APPLSYS.FND_CONCURRENT_PROCESSES c WHERE s.SESSION_ID = c.SESSION_ID;
• Session volume reporting: aggregate rows by EFFECTIVE_DATE to observe session creation trends over a period.
• Orphan detection: identify SESSION_ID values in FND_SESSIONS with no matching concurrent process, indicating dormant or stale registry entries.
• DBA housekeeping: support the concurrent manager's session cleanup routines and capacity planning for the application tier.

Related Objects

The documented relationship set is compact but operationally significant.

• FND_CONCURRENT_PROCESSES — The primary dependent table. Its SESSION_ID column is a foreign key referencing FND_SESSIONS.SESSION_ID. This is the most important join path and the basis for the hub-leaning classification.
• FND_SESSIONS_PK — The primary key constraint on SESSION_ID, providing the uniqueness guarantee used by all dependent joins.
• FND_SESSIONS_U1 — The unique index on (SESSION_ID, EFFECTIVE_DATE), the documented business-key candidate.
• APPLSYS schema objects — As an FND foundation table, FND_SESSIONS participates in the broader Application Object Library model alongside concurrent manager, profile, and user session components.

Because the documented foreign key set is limited to FND_CONCURRENT_PROCESSES, integrators should treat that as the authoritative dependency and confirm any additional consumers directly in their instance metadata before relying on them.