Hi Dojo,
While configuring a display key, I noticed some unexpected behavior. When a NamingFormat tag is defined but the referenced parameter does not exist in the table, for example <NamingFormat>,1</NamingFormat> and parameter 1 is a standalone parameter. DataMiner appears to fall back to using the primary key as the display key. In this fallback scenario, the primary key value is automatically converted to lowercase before being written to the display key column. The same behavior occurs when an invalid display key is defined via the naming options.
Additional testing shows that when no display key configuration is provided at all, the column marked as type="displaykey" is populated with a direct copy of the primary key. In this case, however, no lowercase transformation is applied.
Could you confirm whether this is the intended behavior?
- Is the fallback to the primary key an expected mechanism when the NamingFormat cannot be resolved?
- And is the difference in casing (lowercase vs. original casing) between these scenarios considered normal?
Thanks in advance.
Hi Sofian,
Yes, when a NamingFormat cannot be resolved (e.g., the referenced parameter does not exist or is not part of the key), DataMiner falls back to using the primary key (PK) as the display key (DK).
This matches the documented default behavior:
If no display key is defined or the configured format is invalid, the primary key is used as the display key.
Display keys | DataMiner Docs
The casing difference seems to be expected.
I didn't cover all the test cases, but string DKs are stored cased in the database, and when falling back to string PKs, these are added in lowercase.