Search Results pay_dyndbi_changes




Overview

PAY_DYNDBI_CHANGES is an internal Oracle EBS Payroll (PAY) table owned by the HR schema. Its documented purpose is to control the generation of dynamic database item names, which are the identifiers used by Oracle Payroll's FastFormula engine to reference database items (DBIs) at runtime. Because dynamic database items are constructed programmatically rather than defined statically, the payroll engine requires a mechanism to detect when the underlying definitions or language context have changed so that cached or generated item names can be invalidated and rebuilt. PAY_DYNDBI_CHANGES serves exactly this control function.

The table is extremely narrow, consisting of only three documented columns — ID, TYPE, and LANGUAGE — and is classified as VALID in the ETRM 12.1.1 / 12.2.2 metadata. From a Data Vault modeling perspective, the heuristic classification derived from its foreign key structure is standalone, meaning the table exhibits no mined parent-child relationships and functions as an independent control or configuration structure rather than a hub, link, or satellite in a conventional dimensional model. This classification is a modeling suggestion only; the table's true role is operational and internal to the payroll engine.

Key Information Stored

The documented physical schema for PAY_DYNDBI_CHANGES contains three columns:

  • ID — Part of the composite primary key. Identifies the specific dynamic database item or definition context whose change status is being tracked.
  • TYPE — Part of the composite primary key. Distinguishes the category or nature of the change record, allowing the payroll engine to segregate different classes of dynamic DBI control entries.
  • LANGUAGE — Part of the composite primary key and the language context (for example, a language code such as US or an installed language identifier). This is significant because dynamic database item names can be language-sensitive; multilingual payroll implementations generate distinct item names per language.

The primary key is defined by the unique index PAY_DYNDBI_CHANGES_PK over (ID, TYPE, LANGUAGE). Because the primary key columns collectively form the business identifier, there is no separate surrogate key distinct from the business key — the table is a pure associative control structure. All three columns serve simultaneously as the row identity and as the semantic content of the record. There are no non-key attributes documented, which underscores the table's narrow, flag-like purpose.

Common Use Cases and Queries

PAY_DYNDBI_CHANGES is not intended for end-user reporting. Its principal consumers are Oracle Payroll internals: the FastFormula compilation and DBI generation processes query it to determine whether dynamic database item names must be regenerated. Typical practical scenarios include:

  • Diagnosing stale dynamic database items — When a formula unexpectedly fails to resolve a DBI, checking this table can reveal whether a change record exists that should have triggered regeneration.
  • Multilingual troubleshooting — Filtering by LANGUAGE isolates issues specific to one language installation.
  • Post-patch verification — After applying payroll patches or language installations, DBAs may inspect row counts by TYPE to confirm expected control entries were created.

Representative query patterns, grounded in the documented columns, include selecting all control entries for a given language context or counting records grouped by TYPE to audit the spread of dynamic DBI change categories:

SELECT ID, TYPE, LANGUAGE FROM HR.PAY_DYNDBI_CHANGES WHERE LANGUAGE = :p_language;

SELECT TYPE, COUNT(*) FROM HR.PAY_DYNDBI_CHANGES GROUP BY TYPE;

Direct DML against this table is not supported. Changes should be driven exclusively through the payroll DBI generation and formula compilation processes, which maintain the table automatically.

Related Objects

The ETRM metadata classifies PAY_DYNDBI_CHANGES as standalone, so no foreign key relationships to parent or child tables were mined. Nevertheless, in the broader PAY schema the table is functionally associated with the infrastructure that defines and consumes database items:

  • FF_DATABASE_ITEMS — The core FastFormula repository of database item definitions with which dynamic DBI generation interacts.
  • FF_FORMULAS_F and FF_FORMULA_TYPES — Formulas that reference DBIs and therefore depend on correctly generated dynamic item names.
  • FF_DBI_ROUTES and related routing tables — Control how database items are resolved at runtime, complementing the change-control role of PAY_DYNDBI_CHANGES.
  • FND_LANGUAGES — The installed-language reference backing the LANGUAGE column.
  • PAY_DYNDBI_ITEMS (where present in a given release) — The generated dynamic DBI artifacts whose regeneration this table governs.

Because the table is internal and normally small, administrators should treat it as a diagnostic aid and avoid direct manipulation. Its value lies in explaining why dynamic database items are regenerated, not in providing business data for reporting.