Results for “fnd_lobs”

50+ results




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

Overview

FND_LOBS 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. It stores large object (LOB) content that is managed by the Generic File Manager (GFM) infrastructure, the framework underlying attachments, help documents, and other binary file storage across the EBS technology stack. Each row represents a single managed file, identified by a surrogate primary key, FILE_ID, enforced through the FND_LOBS_PK constraint. The table is not a transactional or operational entity in the business sense; rather, it operates as a shared content repository referenced by dependent application tables that hold the contextual linkage between a business record and its stored file.

Under the heuristic Data Vault classification mined from the foreign key structure, FND_LOBS is best modeled as a hub. It anchors a durable, largely immutable business key (FILE_ID) that many satellite and link tables across multiple products point to, making it the natural candidate for a hub entity in an analytical or integration data model.

Key Information Stored

The documented physical schema for 12.2.2 contains eleven columns. The most significant are:

  • FILE_ID — the surrogate primary key and the value propagated to all dependent tables as a foreign key.
  • FILE_NAME — the display or logical name of the stored file.
  • FILE_CONTENT_TYPE — the MIME type describing the payload (for example, application/pdf or text/plain).
  • FILE_DATA — the actual Large Object column holding the binary or character content.
  • UPLOAD_DATE — the timestamp at which the file was registered with the Generic File Manager.
  • EXPIRATION_DATE — the point at which the content becomes eligible for purge by GFM cleanup programs.
  • PROGRAM_NAME — the concurrent program or process that created the file, useful for provenance and audit.
  • PROGRAM_TAG — a caller-supplied tag used to group files produced by a single program run.
  • LANGUAGE — the language context of the content, relevant for multi-lingual distributions.
  • ORACLE_CHARSET — the character set of character-based content.
  • FILE_FORMAT — the format identifier for the stored object.

FILE_ID is both the primary key and the business-key candidate documented through the unique index FND_LOBS_U1, making it the canonical join value across the schema. The remaining attributes behave as descriptive payload metadata.

Common Use Cases and Queries

Typical operational and reporting scenarios include: identifying orphaned LOB content with no referencing parent row; locating the byte size of stored attachments to plan tablespace growth; auditing uploads by program and date; and resolving the file behind a business attachment.

A representative query joins a dependent table to recover attachment content metadata:

SELECT f.file_id, f.file_name, f.file_content_type,
       f.upload_date, f.expiration_date, f.program_name
FROM   apps.fnd_lobs f
JOIN   apps.jtf_amv_attachments a ON a.file_id = f.file_id
WHERE  a.media_id = :media_id;

Storage-usage reporting is another frequent requirement:

SELECT file_content_type,
       COUNT(*) files,
       SUM(DBMS_LOB.GETLENGTH(file_data))/1024/1024 mb
FROM   apps.fnd_lobs
GROUP  BY file_content_type;

Identifying stale content for purge programs relies on EXPIRATION_DATE and UPLOAD_DATE.

Related Objects

FND_LOBS is referenced by a broad set of dependent tables across multiple products. The most significant documented relationships include:

These references confirm FND_LOBS as a shared hub whose FILE_ID is the common integration key linking stored content to the many business contexts that consume it.