Results for “css_def_attachments_b_pk”

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

Overview

CSS_DEF_ATTACHMENTS_B is a base table within the CSS (Support) product family in Oracle E-Business Suite. The ETRM metadata classifies CSS — Support as obsolete and explicitly notes that this object is "Not implemented in this database." As a result, the table should be treated as a legacy or decommissioned artifact rather than an active transactional object in a typical 12.1.1 or 12.2.2 installation. Where earlier CSS deployments did implement it, the table functioned as the attachment repository for defect records, binding uploaded files stored in the generic file repository to the defect they belong to.

From a Data Vault modeling perspective, the metadata's heuristic classification of this object is link. This is a sensible modeling suggestion: the table's primary purpose is to associate two distinct entities — a defect and a file — through foreign keys, rather than to hold descriptive attributes of a single business key. It is best understood as an associative (junction) structure whose grain is one attachment per row.

Key Information Stored

The documented metadata exposes a small set of columns. The most significant are:

• ATTACHMENT_ID — the surrogate primary key, enforced through the constraint CSS_DEF_ATTACHMENTS_B_PK. This value uniquely identifies each attachment record and is the column most commonly used for direct row lookups.
• DEFECT_ID — foreign key to CSS_DEF_DEFECTS_B. This is the business link that ties an attachment to its owning defect record and is the principal join column for defect-centric reporting.
• FILE_ID — foreign key to FND_LOBS. This points to the actual binary content stored in the shared Oracle EBS file repository, allowing the attachment metadata row to remain lightweight while the file payload resides centrally.

The metadata does not document additional descriptive columns, and no unique business-key index separate from the primary key is specified. In practice, DEFECT_ID combined with FILE_ID would be a natural business-key candidate, but this is not asserted by the ETRM documentation.

Common Use Cases and Queries

Typical scenarios center on retrieving the files attached to a given defect and on auditing the volume of attachments across defects. A minimal lookup by defect might take the form:

• SELECT attachment_id, file_id FROM css_def_attachments_b WHERE defect_id = :defect_id;
• Joining to FND_LOBS on FILE_ID to resolve file name and content for display or extraction.
• Counting attachments per defect to identify heavily documented issues.
• Reconciliation queries that detect attachment rows whose FILE_ID has no corresponding entry in FND_LOBS, indicating orphaned metadata.

Because the object is marked obsolete and "Not implemented," any such queries should be confirmed against the actual schema before deployment, and reporting should not depend on live data being present.

Related Objects

The most significant related objects are those connected through the documented foreign keys and those sharing the DEFECTS naming family:

• CSS_DEF_DEFECTS_B — parent of DEFECT_ID; the defect header table.
• FND_LOBS — parent of FILE_ID; the central file repository holding attachment content.
• CSS_DEF_DEFECTS_TL — the translation table for defect descriptions, frequently joined for reporting.
• FND_ATTACHED_DOCUMENTS / FND_DOCUMENTS — the standard EBS attachment framework, relevant when migrating or replacing this legacy mechanism.
• CSS_DEF_ATTACHMENTS_B_PK — the primary key constraint governing uniqueness of ATTACHMENT_ID.

Together these objects define the attachment-to-defect relationship, and any integration or archival effort should treat CSS_DEF_ATTACHMENTS_B strictly as the link between a defect and a file in FND_LOBS.