Search Results fnd_lobs_documentpart

Overview

FND_LOBS_DOCUMENTPART is a table owned by the APPLSYS schema within the FND — Application Object Library product of Oracle E-Business Suite. According to the ETRM metadata, this table, together with its sibling structures, mirrors the standard WebDB document tables but is implemented under Oracle's own naming convention. Consequently, it functions as an internal storage component that supports the FND_LOBS document management infrastructure, primarily used to hold binary or textual document content associated with the Oracle EBS Application Object Library.

The table is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2, with a documented physical schema containing three columns: DOCUMENT, PART, and UPLOADED. Its primary key is defined as FND_LOBS_DOCUMENTPART_PK over the columns (DOCUMENT, PART). The heuristic Data Vault classification mined from the foreign key structure is "standalone," meaning the table is not modeled as a conventional hub, link, or satellite. In data-vault modeling terms, this suggests the object is best treated as an isolated or self-contained entity rather than a participant in a broader integration pattern; any Data Vault treatment would likely reside outside the core FND_LOBS constellation.

Key Information Stored

The documented metadata identifies a deliberately small column set, reflecting the table's narrow role as a document-part container:

• DOCUMENT — Part of the composite primary key (FND_LOBS_DOCUMENTPART_PK). Identifies the parent document to which the part belongs, serving as a business-key candidate in conjunction with PART.
• PART — The second component of the composite primary key. Denotes the specific segment or part number of the document, enabling large documents to be partitioned across multiple rows.
• UPLOADED — The only non-key column documented in the 12.2.2 physical schema. It likely records the upload state, timestamp, or flag associated with the document part.

The composite primary key (DOCUMENT, PART) is the sole documented unique identifier; no separate surrogate key column is listed in the ETRM metadata. The three-column structure confirms that this is a lightweight bridge-style structure linking document identity to its constituent parts rather than a content-rich entity.

Common Use Cases and Queries

Because FND_LOBS_DOCUMENTPART mirrors WebDB document tables, typical usage centers on diagnostics and support of the FND_LOBS attachment framework. Common scenarios include:

• Enumerating all parts belonging to a given document to verify completeness of an uploaded attachment.
• Auditing which document parts have been uploaded versus pending.
• Investigating attachment failures by correlating part counts against expected values.

A representative query pattern for listing parts by document:

• SELECT DOCUMENT, PART, UPLOADED FROM APPLSYS.FND_LOBS_DOCUMENTPART WHERE DOCUMENT = :document_id ORDER BY PART;
• SELECT DOCUMENT, COUNT(*) AS part_count FROM APPLSYS.FND_LOBS_DOCUMENTPART GROUP BY DOCUMENT HAVING COUNT(*) > 1;

These queries are typically executed by DBAs and technical consultants during attachment troubleshooting or data migration validation, rather than by end users.

Related Objects

The metadata classifies this object as standalone, meaning no explicit foreign keys were mined from the documented structure. Key related objects inferred from the FND_LOBS document infrastructure include:

• FND_LOBS — The parent document registry; joined via the DOCUMENT column to retrieve document-level metadata.
• FND_LOBS_DOCUMENTPART_PK — The primary key constraint enforcing uniqueness on (DOCUMENT, PART).
• FND_ATTACHED_DOCUMENTS — Links attachments to business entities, indirectly relying on document-part storage.
• FND_DOCUMENTS — The document definition table associated with the attachment framework.
• FND_DOCUMENT_ENTITIES — Defines entity relationships for attached documents.

Because the table is documented as standalone, joins to these objects are application-enforced rather than database-enforced through declared foreign keys, and care should be taken when constructing ad hoc queries.