Search Results display_width

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

Overview

AMS_P_ACT_ATTACHMENTS_V is a public view owned by the APPS schema in Oracle E-Business Suite, registered as VALID across releases 12.1.1 and 12.2.2. It belongs to the AMS (Marketing) product family and returns the attachments associated with a marketing activity. In practice the view exposes the metadata and descriptive attributes of marketing collateral — images, documents, links, and other file-based assets — together with the owning user, the physical LOB location, and the decoded attachment type. Because it is a public synonym-style view rather than a private reporting query, it is intended for reuse by Oracle Forms, OAF pages, concurrent programs, and customer-written reports or integrations that need a denormalized, human-readable picture of activity attachments.

Users who search for "jtf_amv_attachments_v" typically arrive here because AMS_P_ACT_ATTACHMENTS_V is the marketing-specific projection layered on top of that generic attachment view. The AMS view narrows the scope to marketing activity attachments and joins in user, LOB, and lookup context that the base view does not decode.

Underlying Base Objects

The view is defined over four documented base objects:

• JTF_AMV_ATTACHMENTS_V (VIEW) — the primary source, aliased A, supplying attachment identity, file attributes, display settings, and the descriptive flexfield columns.
• FND_USER (SYNONYM) — aliased U, joined on A.OWNER_USER_ID = U.USER_ID to resolve USER_NAME.
• FND_LOBS (SYNONYM) — aliased L, joined on A.FILE_ID = L.FILE_ID to supply FILE_FORMAT and the underlying LOB storage reference.
• AMS_LOOKUPS (VIEW) — aliased K, filtered to LOOKUP_TYPE = 'AMS_ATTACHMENT_TYPE' and joined on A.ATTACHMENT_TYPE = K.LOOKUP_CODE to translate the type code into a meaning.

All joins are inner joins, so an attachment row surfaces only when its file, owner, and attachment-type lookup all resolve. Because FND_USER and FND_LOBS are referenced as synonyms, the view depends on the standard APPS synonym layer and is therefore sensitive to the usual 12.1.1/12.2.2 editioning and synonym configuration.

Key Columns

• ROW_ID / ATTACHMENT_ID — unique identifier of the attachment record; ATTACHMENT_ID is the primary business key.
• OWNER_USER_ID / USER_NAME — the FND_USER who owns the attachment, resolved to a display name.
• ATTACHMENT_USED_BY_ID / ATTACHMENT_USED_BY — the marketing activity (or other entity) the attachment is associated with.
• FILE_ID / FILE_NAME / FILE_EXTENSION / FILE_FORMAT — the physical file reference, name, extension, and LOB format.
• ATTACHMENT_TYPE / MEANING — the lookup code and its translated meaning from AMS_LOOKUPS.
• LINK_TO / LINK_URL / DISPLAY_URL — hyperlink and display target information.
• DISPLAY_WIDTH / DISPLAY_HEIGHT / DISPLAY_LOCATION — rendering hints for the attachment.
• VERSION / ENABLED_FLAG / CAN_FULFILL_ELECTRONIC_FLAG — versioning and availability flags.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield storage.
• Standard WHO columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, OBJECT_VERSION_NUMBER.

Common Use Cases and Queries

Typical scenarios include reporting all attachments for a given marketing activity, auditing which users own activity attachments, and locating file formats for migration or cleanup. A representative query lists enabled attachments for a specific activity:

SELECT attachment_id, file_name, file_extension, file_format, meaning, user_name
FROM apps.ams_p_act_attachments_v
WHERE attachment_used_by_id = :activity_id
AND enabled_flag = 'Y';

To audit attachments by owner and type:

SELECT user_name, meaning, COUNT(*)
FROM apps.ams_p_act_attachments_v
GROUP BY user_name, meaning
ORDER BY 3 DESC;

Because the view already resolves user, LOB format, and lookup meaning, these queries avoid the manual joins otherwise required against JTF_AMV_ATTACHMENTS_V, FND_USER, FND_LOBS, and AMS_LOOKUPS. As with any AMS public view, access should be granted through the intended responsibility or a custom APPS-privileged account rather than by direct schema access.