Search Results fnd_imp_depobjects_u1

Overview

APPLSYS.FND_IMP_DEPOBJECTS is a repository table in Oracle E-Business Suite that stores the inventory of dependent objects associated with an implementation snapshot. Its role is to record, for each snapshot, the individual files and metadata belonging to a given application object, thereby supporting the import, comparison, and upgrade processing performed by the FND implementation and patching utilities. The table is owned by APPLSYS, carries the FND design data designation FND.FND_IMP_DEPOBJECTS, holds a VALID status in releases 12.1.1 and 12.2.2, and resides in the APPS_TS_TX_DATA tablespace with PCT Free 10. It is documented with 28 columns.

The supplied metadata classifies this object heuristically as standalone under the Data Vault model. This should be treated as a modeling suggestion rather than a definitive design statement: because the table depends on parent snapshot and security group records rather than forming the hub of a shared business key, it is best modeled as a satellite of the snapshot entity.

Key Information Stored

The two unique indexes identify the table's principal access paths. FND_IMP_DEPOBJECTS_U1, the compound business-key candidate, spans SNAPSHOT_ID, OBJECT_TYPE, and OBJECT_NAME, uniquely identifying a named object of a particular type within a snapshot. FND_IMP_DEPOBJECTS_U2 is a unique index on OBJECT_ID. The non-unique index FND_IMP_DEPOBJECTS_N1 covers SNAPSHOT_ID, OBJECT_TYPE, and APP_SHORT_NAME for filtered lookups.

• SNAPSHOT_ID — the snapshot to which the dependent object belongs; part of both the U1 business key and the N1 access path.
• OBJECT_ID — the numeric identifier of the dependent object, uniquely indexed by U2.
• OBJECT_NAME — the name of the object (VARCHAR2 256), part of the U1 unique key.
• OBJECT_TYPE — the classification of the object (VARCHAR2 50), included in U1 and N1.
• APP_SHORT_NAME — the short name of the owning application, used by the N1 index.
• FILE_DIRECTORY, FILENAME, and FILE_TYPE — the physical location and format of the associated file.
• RCS_ID — the revision control identifier for the file.
• OCHKSUM and FCHKSUM — checksum values used to detect object- and file-level differences.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the generated OAF/BC4J layer.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns.
• SECURITY_GROUP_ID — foreign key to the security group owning the row.
• ATTRIB0 through ATTRIB9 — ten generic VARCHAR2(128) descriptive flexfield-style attribute columns.

Common Use Cases and Queries

Typical usage centers on inventory and reconciliation reporting for a given snapshot or application. Queries filter by SNAPSHOT_ID and OBJECT_TYPE (the N1 path), or probe a single object through OBJECT_ID (U2). The generated query template supplied with the object is a straightforward projection of all 28 columns:

• List all objects for a snapshot: SELECT OBJECT_NAME, OBJECT_TYPE, APP_SHORT_NAME, FILENAME FROM FND_IMP_DEPOBJECTS WHERE SNAPSHOT_ID = :p_snapshot_id ORDER BY OBJECT_TYPE, OBJECT_NAME;
• Resolve a single object: SELECT * FROM FND_IMP_DEPOBJECTS WHERE OBJECT_ID = :p_object_id;
• Compare checksums to detect changed files: SELECT OBJECT_NAME, OCHKSUM, FCHKSUM FROM FND_IMP_DEPOBJECTS WHERE SNAPSHOT_ID = :p_a MINUS SELECT OBJECT_NAME, OCHKSUM, FCHKSUM FROM FND_IMP_DEPOBJECTS WHERE SNAPSHOT_ID = :p_b;
• Count objects per application: SELECT APP_SHORT_NAME, COUNT(*) FROM FND_IMP_DEPOBJECTS WHERE SNAPSHOT_ID = :p_snapshot_id GROUP BY APP_SHORT_NAME;

Related Objects

The documented relationships are:

• AHL_SNAPSHOTS — referenced through FND_IMP_DEPOBJECTS.SNAPSHOT_ID; the parent snapshot record that groups dependent objects.
• FND_SECURITY_GROUPS — referenced through FND_IMP_DEPOBJECTS.SECURITY_GROUP_ID; governs row-level security grouping.

Because these are the only documented foreign keys and the table is classified as standalone, related reporting typically joins back to AHL_SNAPSHOTS for snapshot metadata (name, creation date, and status) and to FND_SECURITY_GROUPS when applying security-filtered views. No additional dependent objects are enumerated in the supplied ETRM metadata, so consumers should treat the FK set above as the authoritative linkage for this object in 12.1.1 and 12.2.2.