Search Results ahm_odf_tab_columns

Overview

AHM_ODF_TAB_COLUMNS is a table within the Oracle E-Business Suite product group AHM – Hosting Manager, which Oracle classifies as obsolete in releases 12.1.1 and 12.2.2. The table stores column information parsed from ADPATCH for the purpose of object creation during the hosting-management provisioning cycle. In practical terms, it functioned as a staging or reference repository where metadata about table columns extracted from Oracle Applications patch (ADPATCH) processing was persisted so that downstream hosting operations could reconstruct or validate table definitions.

The ETRM metadata records that this object is not implemented in the database, meaning no physical instantiation exists in a standard 12.1.1 or 12.2.2 environment. The heuristic Data Vault classification mined from the foreign-key structure is standalone. Under a Data Vault modeling suggestion, this table therefore behaves as neither a hub, link, nor satellite in a conformed warehouse design; it should be treated as an isolated staging entity lacking integration relationships to other modeled hubs or links. Any migration effort would treat it as a disposable load artifact rather than a persistent business entity.

Key Information Stored

The documented primary key is the constraint AOTC_PK, defined over the composite of TABLE_ID, COLUMN_ID, and PATCH_ID. This composite structure is the surrogate identifier for each parsed column record, and the same three columns simultaneously serve as the natural business-key candidates, since they are the only columns documented in the ETRM metadata. The table's payload is consequently minimal:

• TABLE_ID — Identifier of the parsed table for which column metadata is being held; participates in the AOTC_PK composite key.
• COLUMN_ID — Identifier of the individual column within the parsed table; participates in the AOTC_PK composite key.
• PATCH_ID — Identifier of the ADPATCH run or patch from which the column information was parsed; participates in the AOTC_PK composite key and provides the versioning dimension that distinguishes repeated parsing of the same table and column across separate patch applications.

No other columns are documented in the available ETRM metadata. The absence of descriptive attributes, datatype fields, or audit columns reinforces the interpretation that this object was a narrow, transient parse-cache rather than a feature-rich dictionary table. Because the table is not implemented, no DBA data dictionary rows, indexes, or statistics exist for it in a standard environment.

Common Use Cases and Queries

Because AHM_ODF_TAB_COLUMNS is obsolete and unimplemented, direct querying in a production 12.1.1 or 12.2.2 instance will fail with an ORA-00942 object-does-not-exist error. Use cases are therefore historical, forensic, or migration-oriented rather than operational:

• Upgrade impact assessment. Determine whether a customized 11i environment created or populated this table, since such a non-standard object could interfere with a 12.1.1 or 12.2.2 upgrade.
• Legacy data reconciliation. Where a pre-upgrade copy exists, extract the distinct PATCH_ID values to correlate parsed column sets with specific ADPATCH executions.
• Presence detection. A simple existence check against the data dictionary confirms whether an instance ever materialized the object.

A representative pattern would first test for existence and then select the documented key columns:

SELECT table_id, column_id, patch_id FROM ahm_odf_tab_columns WHERE patch_id = :patch_id ORDER BY table_id, column_id;

For upgrade audits, querying DBA_TABLES and DBA_TAB_COLUMNS for OWNER = 'APPLSYS' or the AHM schema name, filtered on TABLE_NAME = 'AHM_ODF_TAB_COLUMNS', is the appropriate verification step. Where the object is present in a legacy database, joining PATCH_ID to a patch-history table provides reporting on which patches contributed column definitions.

Related Objects

The ETRM relationship data classifies AHM_ODF_TAB_COLUMNS as standalone, with no documented foreign keys to or from other tables. The composite key columns nevertheless imply logical dependencies on the broader hosting-management and patch-processing framework:

• ADPATCH-family patch history objects — referenced logically through PATCH_ID, supplying the patch run that produced each parsed column row.
• AHM_ODF_TABLES (by naming convention) — the presumed companion table holding parsed table-level metadata, related on TABLE_ID.
• Other AHM_ODF_* staging tables — sibling parse caches populated from the same ADPATCH processing stream, linked conceptually through PATCH_ID.
• FND_TABLES and FND_COLUMNS — the implemented applications dictionary tables that supersede any staging function this obsolete object performed.
• DBA_TAB_COLUMNS / ALL_TAB_COLUMNS — the Oracle dictionary views used to verify whether the object and its columns exist in a given instance.

No documented API or view references AHM_ODF_TAB_COLUMNS in the provided metadata. Integrations should rely on the implemented FND dictionary tables rather than this obsolete parse-staging object.