Search Results validate_act_attachment

Overview

JTF_AMV_ATTACHMENT_PUB is the public PL/SQL API for document attachments within the Oracle E-Business Suite application technology stack. It is owned by APPS and declared with AUTHID CURRENT_USER, meaning that all unqualified object references resolve under the privileges of the invoking schema rather than the package owner. The package exposes a controlled interface for creating, deleting, and updating attachments that are associated with calling objects, most notably activities managed through the JTF (Common Technology Foundation) schema. Rather than allowing direct DML against the attachment tables, Oracle provides this API so that customizations and extensions can manipulate attachments in a manner consistent with the base application, including record validation and lock management. The package header carries a version marker dated 2002 and the package has been maintained through multiple releases spanning 12.1.1 and 12.2.2, indicating that the interface has remained stable across the EBS product line. Eight other packages reference this API, which confirms its role as a shared foundation component rather than a private implementation detail.

Key Procedures and Functions

The documented procedures fall into three functional groupings. The first group provides the core lifecycle operations:

• CREATE_ACT_ATTACHMENT — creates a new attachment record associated with an activity, populating the attachment record type from caller-supplied values.
• UPDATE_ACT_ATTACHMENT — modifies an existing attachment record, typically after the caller has populated a fetched record structure.
• DELETE_ACT_ATTACHMENT — removes an attachment record and its associated relationship to the owning activity.
• LOCK_ACT_ATTACHMENT — obtains a lock on the attachment record, supporting optimistic concurrency control in multi-user environments.
• VALIDATE_ACT_ATTACHMENT — performs business rule validation against an attachment record before persistence.

The second group supports record manipulation and inspection:

• CHECK_ACT_ATTACHMENT_ITEMS — validates the collection of items associated with an attachment.
• CHECK_ACT_ATTACHMENT_RECORD — validates the contents of an individual attachment record, ensuring required attributes are populated and consistent.

The third group manages record completeness:

• MISS_ACT_ATTACHMENT_REC — identifies attributes that are missing from an attachment record, returning the set of required fields not yet supplied.
• COMPLETE_ACT_ATTACHMENT_REC — the counterpart to the preceding routine; it populates default or derived values so that a partially specified attachment record satisfies all mandatory requirements. This is the procedure most commonly sought by developers searching for the term complete_act_attachment_rec, because it is the standard mechanism for filling mandatory columns without hand-coding defaults.

Tables Accessed

The package operates against the JTF attachment data model through APPS synonyms. JTF_AMV_ATTACHMENTS is the base table holding attachment definitions, including file names, file identifiers, keywords, display dimensions, link targets, language codes, and descriptive text. JTF_AMV_ATTACHMENTS_S is the corresponding sequence or secondary table used during insert processing to generate or manage primary keys. JTF_AMV_ITEMS_B stores the attachment item definitions that relate an attachment to its owning object, and is therefore central to the create and validate operations. DUAL is referenced for simple value retrieval and default assignment, a common pattern in record completion logic. All access is performed through synonyms so that the package remains portable across custom schemas invoking it under AUTHID CURRENT_USER.

Usage Notes

This API is typically invoked from Oracle Forms attachment blocks, from concurrent programs that migrate or load attachments, and from custom PL/SQL that must create attachment records programmatically. The standard pattern is to populate a variable of type act_attachment_rec_type, call MISS_ACT_ATTACHMENT_REC to identify gaps, call COMPLETE_ACT_ATTACHMENT_REC to fill defaults, then call VALIDATE_ACT_ATTACHMENT followed by CREATE_ACT_ATTACHMENT and a COMMIT. Update flows generally acquire a lock through LOCK_ACT_ATTACHMENT before modifying fields. Because the record type and procedure signatures are fixed, callers must use the published record structure and must not assume direct table access. The package does not commit internally; transaction control remains with the calling form, concurrent program, or custom routine.