Search Results sys_il0000034093c00008

Overview

APPLSYS.FND_LOBS_DOCUMENT is a transient staging table in the Oracle E-Business Suite Applications (APPLSYS) schema, designed to hold uploaded document content during the short window between file upload and permanent storage in the core FND_LOBS repository. The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, and its design intent is explicitly documented: WebDB 2.5 inserts rows into these document tables during upload, and the Generic File Manager (GFM) subsequently migrates the rows into FND_LOBS and clears the staging tables. Because of this lifecycle, FND_LOBS_DOCUMENT is expected to remain empty in a steady-state EBS environment — persistent rows are a diagnostic signal that a GFM transfer has not completed.

The object is classified as VALID and carries FND design data reference FND.FND_LOBS_DOCUMENT. Under a heuristic Data Vault classification derived from its foreign-key structure, the table is standalone, meaning it exhibits no inbound or outbound foreign-key relationships to other APPLSYS objects. In Data Vault modeling terms, this suggests treating it as a temporary staging area or a degenerate source rather than a true hub, link, or satellite; it is best modeled alongside the staging pipeline that feeds FND_LOBS.

Key Information Stored

The table is defined with eight columns. The most important of these are:

• NAME (VARCHAR2(256)) — the document file name. This column serves as the primary key of the table via the FND_LOBS_DOCUMENT_PK constraint.
• MIME_TYPE (VARCHAR2(48)) — the MIME type of the uploaded file, for example text/html.
• DOC_SIZE (NUMBER) — the length of the document in bytes.
• DAD_CHARSET (VARCHAR2(128)) — the Database Access Descriptor character set in effect at upload time.
• LAST_UPDATED (DATE) — timestamp of the most recent write to the row.
• CONTENT_TYPE (VARCHAR2(128)) — an interMedia classification of the content as either TEXT or BINARY.
• BLOB_CONTENT (BLOB(4000)) — the actual document payload.
• CONTENT (BLOB(4000)) — documented as not used; retained as a legacy column.

The primary key FND_LOBS_DOCUMENT_PK is defined on NAME. Two LOB indexes — SYS_IL0000034093C00007$$ and SYS_IL0000034093C00008$$ — are documented as unique and are associated with the LOB columns BLOB_CONTENT and CONTENT respectively. These are internal LOB indexes rather than business-key candidates, so NAME remains the sole business-key candidate in the documented schema. The index name in the user's search string, sys_il0000034093c00008, corresponds to the second LOB index shown here.

Common Use Cases and Queries

Because FND_LOBS_DOCUMENT should normally be empty, its most valuable operational use is as a health check: any non-zero row count indicates that GFM has not yet migrated uploaded documents into FND_LOBS. A standard diagnostic query is:

• SELECT COUNT(*) FROM APPLSYS.FND_LOBS_DOCUMENT;
• SELECT NAME, MIME_TYPE, DOC_SIZE, LAST_UPDATED FROM APPLSYS.FND_LOBS_DOCUMENT ORDER BY LAST_UPDATED;
• SELECT NAME, DOC_SIZE, CONTENT_TYPE FROM APPLSYS.FND_LOBS_DOCUMENT WHERE DOC_SIZE > 1000000;

DBAs also use the table to reconcile uploads against FND_LOBS when attachments appear in the UI but not in the underlying repository, and to investigate lock or space pressure in APPS_TS_TX_DATA during large document imports. The documented SELECT template covering NAME, MIME_TYPE, DOC_SIZE, DAD_CHARSET, LAST_UPDATED, CONTENT_TYPE, BLOB_CONTENT, and CONTENT should be applied with caution, since pulling the BLOB columns for large staged documents can consume significant temporary space.

Related Objects

The principal related object is FND_LOBS, the permanent document repository into which GFM moves rows from FND_LOBS_DOCUMENT. The dependency information further records a synonym or wrapper named FND_LOBS_DOCUMENT# that references the base table. On the WebDB side, the upload path inserts into this staging table before GFM processing. Additional operational dependencies include the GFM concurrent program that performs the row transfer and the Database Access Descriptor (DAD) configuration used during upload, which supplies the DAD_CHARSET value. The table does not reference any other database object directly; all of its cross-object relationships are procedural (WebDB insert, GFM move) rather than declarative referential constraints.