Search Results hr_jp_parameters_pk

Overview

HR.HR_JP_PARAMETERS is a seeding and configuration table within the Oracle E-Business Suite Human Resources (HR) schema, registered in the ETRM repository under FND Design Data object PER.HR_JP_PARAMETERS with a status of VALID. The table is documented as a mechanism "used to remove multibyte characters from objects like translation table." In Japanese localizations, multibyte character keys occasionally cause length, collation, or comparison issues when stored or passed between modules. HR_JP_PARAMETERS provides a stable, single-byte surrogate lookup: a consuming module or function (OWNER) resolves a named parameter (PARAMETER_NAME) to a system-generated identification value (PARAMETER_VALUE) that replaces the multibyte key at runtime.

Because the table carries only descriptive configuration data and no transactional or historical attributes — no effective dates, no audit columns, and no foreign key references outward — the heuristic Data Vault classification is standalone rather than hub, link, or satellite. As a modeling suggestion, it is best treated as a reference or code-translation dimension rather than a modeled business entity, and it is not a candidate for a Data Vault hub because its key is a composite of two descriptive attributes rather than a single hashed business key of interest to the enterprise.

Physically, the object resides in the APPS_TS_SEED tablespace, which is consistent with its role as a seeded setup object shipped with the Japanese localization rather than an operational data store. It is defined with PCT Free 10 and no stated PCT Used value, reflecting a small, low-volatility configuration table that is typically populated at installation and rarely updated afterwards.

Key Information Stored

The documented physical schema in ETRM 12.2.2 comprises exactly three columns. Ownership and uniqueness are enforced through the composite primary key index HR_JP_PARAMETERS_PK.

• OWNER (VARCHAR2(30), mandatory) — The module or function that includes the parameters, such as a localization routine or a translation-related program. This column forms the first component of the primary key.
• PARAMETER_NAME (VARCHAR2(30), mandatory) — The name the system uses in place of the multibyte key. This is the second component of the primary key.
• PARAMETER_VALUE (VARCHAR2(80)) — The system-generated identification number associated with the multibyte key. This is the value actually consumed by the calling module.

The surrogate-versus-business-key distinction is unambiguous here: there is no separately generated numeric surrogate identifier. The primary key HR_JP_PARAMETERS_PK is a natural, composite key built from the pair (OWNER, PARAMETER_NAME). The unique index documented in ETRM — HR_JP_PARAMETERS_PK, type NORMAL, uniqueness UNIQUE, in APPS_TS_SEED, on the columns OWNER and PARAMETER_NAME — is the same index that implements the primary key, so the business-key candidate and the primary key are one and the same. No secondary indexes are documented, which is expected for a table of this size.

Common Use Cases and Queries

The principal use case is lookup at runtime by a localization routine that must exchange a multibyte-safe token for its system-generated counterpart. Developers and support analysts query the table to confirm which parameters a given module has registered, to verify the identifier actually in use for a particular parameter name, and to compare configuration between environments after cloning or patching.

The canonical query text published in ETRM selects all three columns:

• SELECT OWNER, PARAMETER_NAME, PARAMETER_VALUE FROM HR.HR_JP_PARAMETERS;
• Filtering by module: add WHERE OWNER = :owner_name to scope results to a single function or routine.
• Direct resolution: add AND PARAMETER_NAME = :parameter_name to retrieve the single PARAMETER_VALUE token used by the calling code.
• Cross-environment or cross-instance comparison: extract all rows from source and target, then diff on the composite key (OWNER, PARAMETER_NAME) to detect configuration drift introduced by patches, data loads, or manual changes.
• Reverse lookup and auditing: group by OWNER to count registered parameters per module, or search PARAMETER_VALUE where a value has been observed elsewhere and its owning parameter must be identified.

Because the table is a seeded reference object, reporting against it is typically diagnostic rather than analytical. A common support pattern is to join the table to the module named in OWNER in order to confirm that the token returned at runtime matches the row the module expects, which is useful when investigating character-corruption symptoms in Japanese-language installations.

Related Objects

The dependency information documented in ETRM is deliberately narrow. HR.HR_JP_PARAMETERS does not reference any database object, so there are no outgoing foreign keys to enumerate. It is referenced by a single dependent object, HR.HR_JP_PARAMETERS#, which is the run-time synonym or editioning view through which the Japanese localization code and other HR programs access the underlying table.

• HR.HR_JP_PARAMETERS# — The dependent object identified in ETRM as referencing HR_JP_PARAMETERS. APPS-level code should generally address this object (or the corresponding APPS synonym) rather than the base table.
• HR.HR_JP_PARAMETERS_PK — The unique index on (OWNER, PARAMETER_NAME) that backs the primary key; any join or correlation on the natural key implicitly relies on it.
• APPS synonyms for HR_JP_PARAMETERS / HR_JP_PARAMETERS# — The standard access path for concurrent programs, forms, and SQL run against the APPS schema in both 12.1.1 and 12.2.2.
• PER.HR_JP_PARAMETERS — The FND Design Data registration under which the object is shipped and patched; relevant when tracking the object through ADOP or earlier patching utilities.

No additional parent tables, APIs, or views are documented as dependencies. Consumers therefore join to HR_JP_PARAMETERS only through the composite key columns OWNER and PARAMETER_NAME, and any integration or extension should do the same.