Results for “fnd_module_installations”

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

Overview

FND_MODULE_INSTALLATIONS is an Oracle E-Business Suite (EBS) repository table owned by the APPLSYS schema and delivered as part of the AD – Applications DBA product. It records the Oracle Application modules that are installed at a given site. Each row associates a module (identified by MODULE_SHORT_NAME) with the application that owns it (APPLICATION_ID) and the Oracle database user under which it is deployed (ORACLE_ID). In EBS 12.1.1 and 12.2.2 this table serves as a registration ledger for module-level installation state, versioning, and status, and is consumed by AD utilities, patching (adpatch), and the AutoConfig tooling to determine which products and modules are present and how they are configured.

From a heuristic Data Vault modeling perspective (mined from the foreign key structure), this object is best classified as a link. It resolves relationships between an application, an Oracle user, and a module, rather than functioning as a standalone hub or as a descriptive satellite.

Key Information Stored

The table contains eleven documented columns. The most significant are:

• APPLICATION_ID – Foreign key to FND_APPLICATION; identifies the owning application (e.g., GL, AP, AR).
• ORACLE_ID – Foreign key to FND_ORACLE_USERID; identifies the Oracle schema/user associated with the module.
• MODULE_SHORT_NAME – Short name/identifier of the installed module.
• STATUS – Application-level installation status of the module.
• DB_STATUS – Database-level status indicator, typically reflecting whether the module's schema objects are valid and active.
• MODULE_VERSION – Version of the installed module.
• LAST_UPDATE_DATE – Timestamp of the most recent modification to the row.
• LAST_UPDATED_BY – User who performed the last update.
• CREATION_DATE – Timestamp when the row was originally created.
• CREATED_BY – User who created the row.
• LAST_UPDATE_LOGIN – Login identifier captured during the last update.

The primary key is FND_MODULE_INSTALLATIONS_PK, defined across APPLICATION_ID, ORACLE_ID, and MODULE_SHORT_NAME. This composite key acts as the business-key candidate, since it uniquely identifies a module installation without a separate surrogate identifier. The standard WHO audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) provide change-tracking metadata.

Common Use Cases and Queries

The table is commonly queried to confirm which modules are installed, to reconcile installation state before or after patching, and to audit module versions across a multi-tier environment.

• Inventory of installed modules by application: join to FND_APPLICATION to translate APPLICATION_ID into human-readable application names and report the modules currently installed.
• Version and status reporting: select MODULE_SHORT_NAME, MODULE_VERSION, STATUS, and DB_STATUS to verify deployment consistency against expected baseline versions.
• DBA user reconciliation: join to FND_ORACLE_USERID on ORACLE_ID to map modules to Oracle schemas.
• Patch and upgrade validation: confirm that modules were correctly re-registered after an adpatch run by inspecting STATUS and LAST_UPDATE_DATE.

A representative query joining the documented foreign keys:

SELECT a.application_short_name, m.module_short_name, m.module_version, m.status, m.db_status, o.oracle_username FROM applsys.fnd_module_installations m, applsys.fnd_application a, applsys.fnd_oracle_userid o WHERE m.application_id = a.application_id AND m.oracle_id = o.oracle_id ORDER BY a.application_short_name, m.module_short_name;

Related Objects

• FND_APPLICATION – joined via APPLICATION_ID; parent application definition.
• FND_ORACLE_USERID – joined via ORACLE_ID; Oracle database user/schema definition.
• FND_MODULE_INSTALLATIONS_PK – composite unique index enforcing the business key.
• AD utilities (adpatch, AutoConfig) and System Administrator product/module listings, which depend on this table for installation state.

Because the documented schema is limited to these two foreign keys, integration and reporting should rely on FND_APPLICATION and FND_ORACLE_USERID as the primary join targets.