Search Results ahm_slot_types

Overview

AHM_SLOT_TYPES is a master (reference) table within the Oracle E-Business Suite Hosting Manager module, designated by the product code AHM. The ETRM metadata explicitly labels this product as "Hosting Manager (Obsolete)," and the object itself carries the implementation note "Not implemented in this database." These two facts are decisive for any reader encountering the name in a search: in a standard Oracle EBS 12.1.1 or 12.2.2 environment, AHM_SLOT_TYPES will not exist as a physical object unless the legacy Hosting Manager product was licensed and installed at some point in the environment's history. The table's documented purpose is to hold the master list of Slot types — that is, the classification values used to categorize "slots," which in the Hosting Manager domain represent discrete hosting capacity or placement units managed by the application.

From a dimensional modeling perspective, the heuristic Data Vault classification supplied in the metadata is standalone. This suggests modeling the table as a hub-like reference entity whose identity is anchored solely on its surrogate key, with no documented parent or dependent links in the FK structure. In practice, this is the classic profile of a small, slowly changing code-and-description lookup table used to constrain and describe transactional or allocation records elsewhere in the obsolete module.

Key Information Stored

The ETRM metadata documents only a limited column set for this object, and no unique business-key index is recorded beyond the primary key. The essential attributes are:

• SLOT_TYPE_ID — the surrogate primary key, defined by constraint AST_PK, uniquely identifying each Slot type record. This is an internally generated identifier with no business meaning.
• Slot type name and description attributes — although the metadata does not enumerate them individually, a master Slot type table of this nature conventionally stores a user-facing type name and a descriptive text field used in setup forms and list-of-values queries.
• Enabled/active flag — a typical attribute controlling whether the type remains selectable.

The metadata does not document any unique index supporting a natural business key. Consequently, the surrogate SLOT_TYPE_ID is the only documented unique identifier, and any business-key candidate would have to be inferred from the application's setup UI rather than from the ETRM record. Analysts should treat the name/description columns as descriptive rather than guaranteed unique.

Common Use Cases and Queries

Because the object is not implemented in standard 12.1.1 and 12.2.2 databases, the primary practical use case is investigative: confirming whether Hosting Manager was ever deployed. A DBA can verify existence with a data dictionary query:

• SELECT table_name, owner FROM all_tables WHERE table_name = 'AHM_SLOT_TYPES';
• SELECT constraint_name, constraint_type, column_name FROM all_cons_columns WHERE table_name = 'AHM_SLOT_TYPES'; — confirming the AST_PK primary key on SLOT_TYPE_ID.

Where the table is present in a legacy environment, reporting use cases include retrieving the set of valid Slot types for a setup or migration listing:

• SELECT slot_type_id, slot_type_name FROM ahm_slot_types ORDER BY slot_type_name;
• Joining the master to any dependent allocation or capacity table on SLOT_TYPE_ID to resolve the descriptive type name for capacity reports.

Related Objects

The ETRM relationship data classifies AHM_SLOT_TYPES as standalone, meaning no foreign keys from this table are documented. Any related objects would therefore be child tables referencing SLOT_TYPE_ID, plus module-level setup and concurrent programs. The most plausible related artifacts are:

• AHM slot/allocation transaction tables that carry SLOT_TYPE_ID as a foreign key to this master.
• AHM setup and validation views or LOV definitions that source their values from AHM_SLOT_TYPES.
• Concurrent programs and setup forms within the Hosting Manager module that maintain Slot type definitions.

Given the obsolete status, organizations performing upgrades from 12.1.1 to 12.2.2 should treat any dependency on this table as a migration risk and confirm that the Hosting Manager module is not required before removing or archiving it.