Results for “data_type”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CZ_DB_SETTINGS is the repository of system-level configuration settings for Oracle Configurator, the rules-based configuration engine embedded in Oracle E-Business Suite. The table resides in the CZ schema and is classified as VALID in both the 12.1.1 and 12.2.2 releases, although the physical footprint differs between them. In 12.1.1 the table contains the core setting, section, data type, value, and description columns; in 12.2.2 the editioning column ZD_EDITION_NAME is added, bringing the documented column count to six.

Functionally, the table acts as a key-value store. Each row supplies the value of a named Configurator setting within a named section, allowing the Configurator runtime and its administrative UI to resolve operational parameters without code changes. Settings controlled at this level govern behaviors such as cache handling, UI rendering options, and runtime limits used during configuration model execution and validation.

The heuristic Data Vault classification mined from the foreign-key structure is standalone. In Data Vault modeling terms this suggests the object behaves as a self-contained reference or hub-like structure with no outbound dependent links, and therefore needs no satellite or link decomposition to be represented faithfully. Because the settings are administrator-maintained rather than transactionally generated, the table behaves more like a reference data set than a transactional entity.

Key Information Stored

• SECTION_NAME — the logical grouping of related settings; forms the first component of the primary key.
• SETTING_ID — the identifier of the individual setting within its section; forms the second component of the primary key.
• DATA_TYPE — the declared data type of the setting, used by the Configurator to interpret and validate VALUE.
• VALUE — the actual value assigned to the setting, stored in the representation appropriate to DATA_TYPE.
• DESC_TEXT — descriptive text explaining the purpose or acceptable values of the setting.
• ZD_EDITION_NAME — the editioning column present in 12.2.2, which participates in the unique index CZ_DB_SETTINGS_U1 and supports Online Patching (adop) edition-based redefinition.

The surrogate primary key is CZ_DB_SETTINGS_PK, defined on the composite of SECTION_NAME and SETTING_ID. The business-key candidate is the unique index CZ_DB_SETTINGS_U1, defined on SECTION_NAME, SETTING_ID, and ZD_EDITION_NAME. The distinction matters for direct data manipulation: application logic should be written against the pair used by the primary key, while queries that must respect patch edition scoping in 12.2.2 should also filter or join on ZD_EDITION_NAME.

Common Use Cases and Queries

The most frequent requirement is simply retrieving the effective value of a named setting, typically to confirm the current configuration of a Configurator environment before or after a patch. A representative query is:

• SELECT section_name, setting_id, data_type, value, desc_text FROM cz.cz_db_settings WHERE section_name = :section;
• Lookup of a single parameter: SELECT value FROM cz.cz_db_settings WHERE section_name = :section AND setting_id = :setting;
• Reporting on non-default or unusually typed values by aggregating over DATA_TYPE.
• Comparison of settings between a source and a cloned environment, joining on SECTION_NAME and SETTING_ID to detect drift.
• In 12.2.2 only, scoping results by edition: SELECT ... WHERE zd_edition_name = :edition;

Because the table is small and rarely modified, it is safe to query directly in reporting and support diagnostics, and it is commonly used to document the baseline configuration of a Configurator instance during implementation or audit. Any update should be performed through the supported Configurator administration interface rather than by direct DML, since the application may cache resolved values.

Related Objects

No foreign-key dependencies are documented for CZ_DB_SETTINGS; its relationship classification is standalone, meaning it neither references nor is referenced by other tables through foreign-key constraints. Consequently, related objects are identified by conformance and usage rather than by declarative integrity:

• CZ_DB_SETTINGS_PK — the primary key constraint governing uniqueness of SECTION_NAME and SETTING_ID.
• CZ_DB_SETTINGS_U1 — the unique index extending the key with ZD_EDITION_NAME in 12.2.2.
• The Configurator administrative UI and concurrent programs in the CZ product module that read and maintain these settings.
• Other CZ schema configuration and model tables, joined logically on section and setting naming conventions rather than on foreign keys.

Because referential integrity is absent, joins to this table are always predicate-driven: applications and reports must supply the correct SECTION_NAME and SETTING_ID values, and in 12.2.2 the applicable edition, to obtain the intended row.