Search Results ad_check_files




Overview
Explore in AI Chat

Overview

The AD_CHECK_FILES table is a core Applications DBA (AD) repository within the Oracle E-Business Suite (EBS) APPLSYS schema. Its primary function is to serve as a checkfile registry, systematically tracking the highest version of executable SQL and program files that have ever been run on the system. This table is fundamental to the patching and upgrade architecture of EBS, enabling the AD utilities (such as AutoPatch) to determine whether a specific file version from a patch has already been applied. By maintaining this historical version control, it prevents the redundant execution of upgrade scripts, ensuring data integrity and consistency across the application tier and database during maintenance operations.

Key Information Stored

The table's structure is designed to uniquely identify and version application files. While the full column list is not detailed in the provided metadata, its defined primary and foreign keys reveal its critical data points. The CHECK_FILE_ID column serves as the primary key, uniquely identifying each record in the repository. The FILE_ID column is a foreign key linking to the AD_FILES table, which contains metadata about the file itself (e.g., filename, application). The FILE_VERSION_ID column is a foreign key linking to the AD_FILE_VERSIONS table, storing the specific version details. Collectively, a record in AD_CHECK_FILES signifies that a particular file (FILE_ID) has been executed at least up to a specific version (FILE_VERSION_ID), and this version is the highest one recorded for that file.

Common Use Cases and Queries

The primary use case is during patch application, where the AD utilities query this table to decide if a script needs to be run. DBAs may also query it for auditing and reporting on the patching history of the system. A common diagnostic query involves joining to related tables to see the status of specific files. For example, to list the highest applied version for files in a particular application:

  • SELECT f.FILE_NAME, f.APP_SHORT_NAME, v.VERSION
    FROM APPLSYS.AD_CHECK_FILES cf,
    APPLSYS.AD_FILES f,
    APPLSYS.AD_FILE_VERSIONS v
    WHERE cf.FILE_ID = f.FILE_ID
    AND cf.FILE_VERSION_ID = v.FILE_VERSION_ID
    AND f.APP_SHORT_NAME = 'PO';

Another critical pattern is verifying if a specific file version from a new patch is already recorded, which would instruct AutoPatch to skip its execution.

Related Objects

The AD_CHECK_FILES table is centrally linked to two other key AD tables, as defined by its foreign key constraints:

  • AD_FILES: Related via the foreign key column AD_CHECK_FILES.FILE_ID. This table stores master information about executable files managed by AutoPatch.
  • AD_FILE_VERSIONS: Related via the foreign key column AD_CHECK_FILES.FILE_VERSION_ID. This table stores the specific version numbers and other attributes for the files referenced in AD_FILES.

The primary key constraint AD_CHECK_FILES_PK on CHECK_FILE_ID ensures the uniqueness of each version tracking record. This set of tables forms the backbone of the EBS file versioning system.