Search Results file_version_id




Overview

The AD_FILE_VERSIONS table is a core repository within the Oracle E-Business Suite (EBS) Applications DBA (AD) module, owned by the APPLSYS schema. It serves as the central registry for tracking specific version instances of every file that constitutes the Oracle Applications technology stack and product file system. Its primary role is to provide a granular, versioned inventory of all software components, enabling precise patch management, system audits, and dependency tracking. This table is fundamental to the EBS architecture, as it underpins the AD utilities' ability to manage, compare, and validate file states during operations like patching, cloning, and upgrades in both releases 12.1.1 and 12.2.2.

Key Information Stored

While the provided metadata does not list individual columns, the table's structure can be inferred from its relationships and purpose. The primary key is FILE_VERSION_ID, a unique identifier for each version record. A critical foreign key is FILE_ID, which links to the parent AD_FILES table that holds the master file definition (e.g., file path, name). Each record in AD_FILE_VERSIONS represents a distinct instance or release of that file. Other columns typically store version-specific metadata such as the version number or label, checksum information for integrity validation, timestamps for creation or application, and potentially status flags. This design allows multiple version records to be associated with a single file definition, creating a complete version history.

Common Use Cases and Queries

The table is essential for diagnostic and administrative reporting. A common use case is identifying the current version of files applied to an instance, particularly after a patch. Administrators can query to verify patch application or diagnose version mismatches. Another key scenario is during patch analysis, where utilities compare file versions in the patch driver (AD_PATCH_RUN_BUG_ACTIONS) against those onsite or in the database. A sample query might join AD_FILES to AD_FILE_VERSIONS to list all versions for files in a specific directory:

  • SELECT f.file_name, f.file_path, v.version_label, v.creation_date FROM applsys.ad_files f, applsys.ad_file_versions v WHERE f.file_id = v.file_id AND f.file_path LIKE '%/java/%;

It is also heavily used by the AD utilities themselves for snapshot comparisons (via AD_SNAPSHOT_FILES) and file integrity checks (via AD_CHECK_FILES).

Related Objects

AD_FILE_VERSIONS is a central hub with documented foreign key relationships to several critical AD tables, as per the provided metadata:

  • AD_FILES: The parent table. Joined via AD_FILE_VERSIONS.FILE_ID to AD_FILES.
  • AD_CHECK_FILES: References a file version for integrity checking via AD_CHECK_FILES.FILE_VERSION_ID.
  • AD_PATCH_RUN_BUG_ACTIONS: Has three separate foreign key references to this table, linking to specific file versions involved in a patch action: PATCH_FILE_VERSION_ID, ONSITE_FILE_VERSION_ID, and ONSITE_PKG_VERSION_IN_DB_ID.
  • AD_SNAPSHOT_FILES: References a file version captured in a system snapshot via AD_SNAPSHOT_FILES.FILE_VERSION_ID.

These relationships highlight its integral role in the patch lifecycle, system validation, and snapshot management processes.