Search Results ad_check_file_temp

Overview

AD_CHECK_FILE_TEMP is a transient interface (staging) table owned by the APPLSYS schema in Oracle E-Business Suite, belonging to the AD – Applications DBA product group. Its documented purpose is to serve as the loading interface for files, file versions, and checkfile repositories. During patching, AD administration, and file-system synchronization operations, external processes populate this table with file metadata that is subsequently validated and merged into the permanent repository tables such as AD_FILE_VERSIONS and AD_CHECK_FILES.

The ETRM metadata classifies this object heuristically as standalone from a Data Vault perspective, meaning it does not behave as a durable hub, link, or satellite in the modelled repository. Rather, it functions as an ephemeral staging structure whose rows are consumed and purged by concurrent AD utilities. This classification should be treated as a modelling suggestion; the table is operational in nature and not intended as a system-of-record.

Key Information Stored

The table carries 32 documented columns in release 12.2.2, organized around a file identity plus a mirrored destination set. The most significant columns include:

• FILE_ID / FILE_VERSION_ID / CHECK_FILE_ID / APPL_TOP_ID – foreign keys to AD_FILE_VERSIONS, AD_CHECK_FILES, and AD_APPL_TOPS, anchoring each staged row to the permanent repository entries.
• APP_SHORT_NAME, SUBDIR, FILENAME – the business coordinates of the source file within an APPL_TOP, forming a natural business-key candidate.
• DEST_FILE_ID, DEST_APPS_SHORT_NAME, DEST_SUBDIR, DEST_FILENAME – the mirrored destination coordinates used when a file is copied or linked between APPL_TOP locations.
• FILE_SIZE, CHECK_SUM – physical verification attributes used to detect file corruption or drift.
• MANIFEST_VERS, MANIFEST_VERS_HIGHER, MANIFEST_VERS_2 – manifest versioning columns that control which patch level introduced or modified the file.
• TRANSLATION_LEVEL, LANGUAGE, ACTIVE_FLAG, INCONSISTENT_FLAG – status and locale flags governing whether the row is applied.
• FILE_TYPE_FLAG and the four SERVER_TYPE_*_FLAG columns (ADMIN, FORMS, NODE, WEB) – indicate which server tier the file targets.
• EFFECTIVE_DATE, DISTINGUISHER, JUNK – control columns used for sequencing and merge logic.

No formal primary key is documented; the surrogate identifier in practice is FILE_VERSION_ID combined with the APPL_TOP/code coordinates, while the business-key candidate is the tuple (APP_SHORT_NAME, SUBDIR, FILENAME) within a given APPL_TOP.

Common Use Cases and Queries

DBAs and patching engineers query AD_CHECK_FILE_TEMP primarily to diagnose failed or partial patch application. Typical scenarios include verifying that staged files were merged into the repository, detecting checksum mismatches, and auditing translation-level propagation.

A representative diagnostic query lists staged files whose version was never promoted:

• SELECT app_short_name, subdir, filename, file_version_id, inconsistent_flag FROM applsys.ad_check_file_temp WHERE inconsistent_flag = 'Y';
• SELECT t.filename, t.file_size, t.check_sum FROM applsys.ad_check_file_temp t WHERE t.check_file_id IS NULL;
• SELECT t.app_short_name, COUNT(*) FROM applsys.ad_check_file_temp t GROUP BY t.app_short_name ORDER BY 2 DESC;

Because the table is transient, reporting use is limited to active patch windows; after successful merge the AD utilities typically truncate or delete processed rows.

Related Objects

The FK metadata identifies the principal dependents:

• AD_FILE_VERSIONS – joined via FILE_VERSION_ID, the authoritative version registry.
• AD_CHECK_FILES – joined via CHECK_FILE_ID, holding checksum and file-state records.
• AD_APPL_TOPS – joined via APPL_TOP_ID, defining the application tier location.

Operationally, AD_CHECK_FILE_TEMP also interacts with AD_MANIFEST and AD_FILE_SYSTEM utilities that load it, and with AD_PATCH driver processes that read the merged results.