Search Results rla_demand_lines_archive_all

Overview

RLA_DEMAND_LINES_ARCHIVE_ALL is a database table within the Oracle E-Business Suite Release Management Integration Kit (RLA) module. As its name indicates, it serves as an archival repository for Release Management demand line records. In the context of Oracle EBS 12.1.1 and 12.2.2, the RLA module provided integration between EBS and external release management processes, and this table preserved historical demand line data after those records had been purged or superseded in the active transactional tables.

Notably, Oracle's own documentation flags the RLA product as obsolete and states that this table is "Not implemented in this database." Consequently, the table should not be expected to hold data or be referenced by active application logic in a standard 12.1.1 or 12.2.2 environment. It remains catalogued for completeness and for environments that may have historically enabled the RLA integration kit.

The provided metadata assigns a heuristic Data Vault classification of standalone. Within a Data Vault modeling suggestion, this indicates the table is not currently modeled as a hub, link, or satellite deriving from foreign-key relationships, but rather functions as an independent archival structure. This classification is heuristic and mined from the absence of FK relationships, so treat it as a modeling suggestion rather than a definitive architectural mandate.

Key Information Stored

The documented structure centers on a composite primary key and an archive marker. Oracle does not enumerate every column in the supplied metadata, so only documented attributes are described below.

• DEMAND_LINE_ID — Part of the composite primary key. This identifier references the underlying demand line; it is the business-key candidate linking the archived record back to its original transactional source.
• ARCHIVE_TIMESTAMP — The second component of the composite primary key. It records the moment the demand line was archived, enabling temporal reconstruction and distinguishing multiple archived versions of the same demand line over time.

The composite primary key RLA_DEMAND_LINES_ARCHIVE_PK is defined on (DEMAND_LINE_ID, ARCHIVE_TIMESTAMP). Here, DEMAND_LINE_ID functions as the business-key candidate, while ARCHIVE_TIMESTAMP differentiates successive archival events. No separate single-column surrogate key is documented. The combination of these two columns is what guarantees uniqueness within the archive.

Common Use Cases and Queries

Because the RLA module is obsolete and the table is not implemented in current databases, practical usage in 12.1.1 and 12.2.2 is limited. Typical scenarios where an administrator or analyst might investigate this object include:

• Historical audit and traceability — Reconstructing the state of demand lines as they existed at a point in time, using ARCHIVE_TIMESTAMP to order versions.
• Migration or upgrade assessment — Confirming whether legacy RLA data exists before upgrading from 12.1.1 to 12.2.2, to decide whether archival cleanup is required.
• Data lineage research — Tracing a DEMAND_LINE_ID from active tables into its archived counterparts.

A representative query pattern retrieves the latest archived version of a given demand line:

• SELECT DEMAND_LINE_ID, ARCHIVE_TIMESTAMP FROM RLA_DEMAND_LINES_ARCHIVE_ALL WHERE DEMAND_LINE_ID = :id ORDER BY ARCHIVE_TIMESTAMP DESC;
• To count archived records per day: SELECT TRUNC(ARCHIVE_TIMESTAMP), COUNT(*) FROM RLA_DEMAND_LINES_ARCHIVE_ALL GROUP BY TRUNC(ARCHIVE_TIMESTAMP);

Related Objects

The metadata classifies this table as standalone, meaning no foreign-key relationships are documented from this structure. As a result, the most significant related objects are conceptual rather than formally constrained by FK definitions:

• RLA_DEMAND_LINES_ALL — The active (non-archived) demand lines table; this archive is the historical counterpart. Join candidate: DEMAND_LINE_ID.
• RLA_DEMAND_LINES_ARCHIVE_PK — The primary key constraint object defined over (DEMAND_LINE_ID, ARCHIVE_TIMESTAMP).
• Release Management (RLA) concurrent programs — Archive and purge processes that populated this table when the module was active.
• Other RLA archive tables — Sibling archival tables for related release management entities, sharing the archive convention.

Because no FK relationships are documented, joins to active RLA tables must be established manually via DEMAND_LINE_ID rather than being enforced by the database. Analysts should verify object existence and row counts before relying on any join logic.