Search Results fnd_lobs_document




Overview
Explore in AI Chat

Overview

FND_LOBS_DOCUMENT is a table owned by the APPLSYS schema within the FND — Application Object Library product of Oracle E-Business Suite. According to the ETRM documentation, this table and its siblings mirror the standard WebDB document tables but use Oracle EBS-specific naming conventions. In practical terms, FND_LOBS_DOCUMENT serves as the physical storage repository for large binary and character content managed by the FND_LOBS infrastructure, which underpins features such as file uploads, attachments, document attachments, and other interfaces where non-structured content must be persisted directly in the database rather than on the file system.

The metadata provides no explicit foreign key relationships, and the heuristic Data Vault classification mined from the FK structure identifies this object as standalone. From a modeling perspective, this suggests FND_LOBS_DOCUMENT should be treated as an independent hub-like repository rather than a dependent satellite or link. Its primary key, FND_LOBS_DOCUMENT_PK, is defined on the NAME column, which acts as the sole business identifier linking stored content back to its logical document record.

Key Information Stored

The documented physical schema contains eight columns. The most significant are:

  • NAME — the primary key column and the business identifier of the document. This value is referenced by FND_LOBS and related attachment records to resolve the corresponding binary content.
  • BLOB_CONTENT — the binary large object column holding the actual file payload for binary documents such as images, PDFs, spreadsheets, and Office files.
  • CONTENT — the character large object (CLOB) column holding textual content when the document is stored as text rather than binary.
  • MIME_TYPE — the MIME type describing the format of the stored content, used by clients and application logic to render or download the document correctly.
  • CONTENT_TYPE — a secondary type indicator associated with the document record.
  • DOC_SIZE — the size of the document content, useful for capacity planning and validation.
  • DAD_CHARSET — the character set associated with the WebDB-style document handling, relevant for correct text decoding.
  • LAST_UPDATED — the timestamp of the most recent modification to the document record.

Two LOB indexes are documented — SYS_IL0000034093C00007$$ and SYS_IL0000034093C00008$$ — which are internal LOB indexes supporting the BLOB_CONTENT and CONTENT columns. These are not business-key candidates; the sole unique identifier remains FND_LOBS_DOCUMENT_PK on NAME.

Common Use Cases and Queries

The primary use case is resolving a document identifier to its stored content. A typical query retrieves metadata without loading the LOB payload:

SELECT name, mime_type, doc_size, last_updated
FROM   applsys.fnd_lobs_document
WHERE  name = :document_name;

When the full content is required, the LOB columns are selected directly, often alongside the FND_LOBS record that references the same NAME. Reporting scenarios include auditing document storage volume by MIME type, identifying stale documents by LAST_UPDATED, and reconciling content sizes between FND_LOBS metadata and FND_LOBS_DOCUMENT payloads. Administrators may also query for documents exceeding size thresholds to support purge and archival routines.

Related Objects

The most significant related objects include:

  • FND_LOBS — the primary metadata sibling table, joined on the shared NAME identifier, holding the logical document record that points to the content in FND_LOBS_DOCUMENT.
  • FND_ATTACHED_DOCUMENTS — links application entities (such as invoices, orders, or requisitions) to document identifiers resolvable through FND_LOBS.
  • FND_DOCUMENTS and FND_DOCUMENT_ENTITIES — define document categories and entity associations used by the attachment framework.
  • FND_LOBS_DOCUMENT_PK — the primary key constraint enforcing uniqueness on NAME.
  • FND_LOBS_DOCUMENT LOB indexes (SYS_IL0000034093C00007$$, SYS_IL0000034093C00008$$) — internal indexes supporting LOB access.

Because the heuristic classification is standalone, no foreign keys originate from this table; relationships to application objects are resolved logically through the NAME column rather than through enforced referential constraints.