Search Results frm_archived_lobs_pk

Overview

FRM_ARCHIVED_LOBS is a Report Manager (FRM) repository table in the Oracle E-Business Suite database, owned by the FRM schema. Its documented purpose is to store Report Manager large object (LOB) files, including report output and third-party files. In practice, this table functions as the durable storage layer for published report artifacts — the binary or character content that end users retrieve through the Report Manager interface after a concurrent request completes. Because Report Manager serves as the central publishing and viewing mechanism for concurrent program output across all EBS modules, FRM_ARCHIVED_LOBS underpins report retrieval, reprint, and archival behavior throughout the application.

The documented schema shows thirteen columns and a primary key constraint, FRM_ARCHIVED_LOBS_PK, defined on FILE_ID. The heuristic Data Vault classification mined from the foreign key structure is standalone, meaning the table exhibits no documented outbound foreign key relationships to other EBS entities. As a modeling suggestion, this indicates FRM_ARCHIVED_LOBS behaves less like a conventional hub or link and more like an isolated satellite or content store: its rows are addressed by their own identifier rather than through shared business keys inherited from a parent entity.

Key Information Stored

The table's identity and content columns carry the substantive data:

• FILE_ID — The surrogate primary key, enforced by FRM_ARCHIVED_LOBS_PK and also carried by the unique index FRM_ARCHIVED_LOBS_UK1. Every LOB row is uniquely identified by this value.
• FILE_NAME — The name assigned to the stored artifact, used for display and retrieval in Report Manager.
• FILE_CONTENT_TYPE — The MIME or content classification of the stored file, permitting correct rendering of heterogeneous output formats.
• FILE_DATA — The large object payload itself; this is the column that holds the actual report output or third-party file content, and it is the reason the table is one of the largest consumers of storage in many EBS environments.
• UPLOAD_DATE — The date the file was placed into the archive.
• EXPIRATION_DATE — The date on which the archived file becomes eligible for purge or cleanup processing.
• PROGRAM_NAME — Identifies the concurrent program that produced the file, linking content back to its originating process.
• PROGRAM_TAG — A tag value further qualifying the producing run or program instance.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — The standard EBS audit columns recording who created and last modified each row and when.

It is worth distinguishing the surrogate key from any business-key candidate: the documentation lists FRM_ARCHIVED_LOBS_UK1 on FILE_ID alone, so no natural business key distinct from the surrogate identifier is documented for this table.

Common Use Cases and Queries

The most frequent operational use cases revolve around report retrieval, storage consumption analysis, and purging.

• Locating output for a specific report program: query by PROGRAM_NAME, optionally constrained by UPLOAD_DATE, to enumerate archived artifacts.
• Storage and capacity reporting: aggregate row counts and approximate LOB sizes by program or by upload date to identify heavy consumers.
• Expiry and purge management: identify rows where EXPIRATION_DATE has passed, typically in coordination with Report Manager purge logic.
• Audit and traceability: use CREATED_BY, CREATION_DATE, and PROGRAM_TAG to trace who ran what and when.

A representative pattern selects metadata without touching FILE_DATA, since including the LOB column is expensive:

• SELECT file_id, file_name, file_content_type, program_name, upload_date, expiration_date FROM frm.frm_archived_lobs WHERE program_name = :program AND upload_date >= :from_date;

Because FILE_DATA is an actual LOB segment, direct selection of that column should be reserved for cases where the content itself is genuinely required.

Related Objects

The mined relationship data indicates FRM_ARCHIVED_LOBS is standalone, with no documented foreign keys to other tables. This is significant: unlike transactional EBS tables that join to a hub through shared identifiers, archived LOB records are effectively self-contained. In consequence, the meaningful related objects are those in the broader Report Manager subsystem rather than FK-linked parents or children. These include the Report Manager concurrent program definitions referenced by PROGRAM_NAME and PROGRAM_TAG in FND_CONCURRENT_PROGRAMS and FND_CONCURRENT_REQUESTS, the FND_LOBS repository that stores generic EBS LOB content, and the Report Manager purge and archival concurrent programs that read EXPIRATION_DATE to reclaim space. Report output display in the EBS Forms-based Report Manager viewer depends on this table through the FRM schema's internal access paths rather than through declared referential constraints.