Search Results sys_il0000399302c00004

Overview

FRM.FRM_REPOSITORY_LOBS is the Oracle E-Business Suite Report Manager repository table responsible for persisting large binary objects associated with concurrent processing. As documented in the ETRM metadata for EBS 12.1.1 and 12.2.2, the table "stores the Report Manager large object files, such as report output and 3rd party files." It is owned by the FRM schema, is registered under FND Design Data as FRM.FRM_REPOSITORY_LOBS, holds a status of VALID, and resides in the APPS_TS_MEDIA tablespace with a PCTFREE of 10 — a storage choice consistent with the media-oriented nature of the content.

From a modeling perspective, the heuristic Data Vault classification supplied with the metadata is standalone. In practical terms this indicates the table is treated as an independent entity rather than participating in a hub-and-link fabric; it has no documented foreign-key dependencies and no downstream references. The documented primary key is FRM_REPOSITORY_LOBS_PK on FILE_ID, and the metadata notes that FRM_REPOSITORY_LOBS does not reference any parent object.

Key Information Stored

Each row represents a single stored file — commonly a report output produced by a concurrent program — identified by the surrogate primary key FILE_ID (NUMBER(15)), documented as the "Entity Identifier across all applications." Business-key uniqueness is enforced by FRM_REPOSITORY_LOBS_UK1, a unique index on FILE_ID in APPS_TS_MEDIA.

• FILE_NAME (VARCHAR2(256)) — the name of the stored file.
• FILE_CONTENT_TYPE (VARCHAR2(256)) — the type of large object being stored.
• FILE_DATA (BLOB) — the primary binary large object payload.
• FODATA (BLOB) — the binary large object data for HTML output, governed by ATTRIBUTE1.
• ATTRIBUTE1 (VARCHAR2(256)) — the boolean flag specifying whether FODATA is populated.
• UPLOAD_DATE and EXPIRATION_DATE (DATE) — lifecycle timestamps marking upload and the point at which the object is no longer required. EXPIRATION_DATE is indexed non-uniquely by FRM_REPOSITORY_LOBS_N1.
• PROGRAM_NAME (VARCHAR2(240)) and PROGRAM_TAG (VARCHAR2(32)) — the program that manipulated the LOB and an optional categorization string used by the GFM client.
• CREATION_DATE, CREATED_BY, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, LAST_UPDATE_DATE — standard WHO audit columns.

Two LOB segment entries, SYS_IL0000399302C00004$$ and SYS_IL0000399302C00014$$, appear in the index listing and correspond to the underlying LOB storage for FILE_DATA and FODATA. The identifier queried by the user is one such system-generated LOB index name.

Common Use Cases and Queries

Typical scenarios include auditing Report Manager output, diagnosing expired or orphaned LOBs, and reconciling concurrent program output volumes.

• Retrieve metadata for a specific file: SELECT file_id, file_name, file_content_type, upload_date, expiration_date FROM frm.frm_repository_lobs WHERE file_id = :p_file_id;
• Report objects by producing program: SELECT program_name, COUNT(*) FROM frm.frm_repository_lobs GROUP BY program_name;
• Identify stale content using the indexed expiry column: SELECT * FROM frm.frm_repository_lobs WHERE expiration_date < SYSDATE;
• Detect HTML-versus-binary storage: SELECT file_id, program_tag, attribute1 FROM frm.frm_repository_lobs WHERE attribute1 = 'Y';

Because FILE_DATA and FODATA are BLOBs, reporting queries should project scalar columns only, retrieving content selectively by FILE_ID to avoid full-table LOB reads.

Related Objects

The documented metadata confirms that FRM.FRM_REPOSITORY_LOBS does not reference other objects and is classified as standalone, so no explicit foreign-key joins are documented. Related functionality is instead associated at the reporting and concurrent-processing layer:

• FND_CONCURRENT_REQUESTS — the request record that initiates the Report Manager output persisted here.
• FND_CONCURRENT_PROGRAMS — supplies the program definition corresponding to PROGRAM_NAME.
• FND_LOBS — the parallel Framework LOB repository for the FND schema.
• FRM_REPOSITORY_LOBS indexes — FRM_REPOSITORY_LOBS_PK, FRM_REPOSITORY_LOBS_UK1, and FRM_REPOSITORY_LOBS_N1.
• XDO_LOBS — the XML Publisher/BI Publisher LOB store used by related output templates.

Cross-referencing FILE_ID against FND_CONCURRENT_REQUESTS remains the most reliable means of associating stored content with its originating request.