Skip to main content

languages for personalization / customization causing issues DB side / Data types issue

  • April 2, 2026
  • 0 replies
  • 1 view

REOGIRARD
Hero (Customer)
Forum|alt.badge.img+9

While attempting to add a query as an entity in a projection in IFS Cloud 24R1, I encountered the following error:

"The query ShopOrderTool is not published."


This occurred while my session language was set to French. Under normal circumstances, I work in English.

The query appears to be correctly published, as it is available and selectable in the dynamic list. However, the validation still fails during the projection configuration.

To better understand the behavior, I investigated further at the database level. It seems that the validation relies on a comparison against a string value ('True') returned by the Get_Published function. When the session language is set to French, this function instead returns "Vrai", which causes the condition to fail.

Relevant code snippet:

PROCEDURE Check_Query_Published (
query_ IN VARCHAR2 )
IS
BEGIN
General_SYS.Init_Method(Query_Artifact_API.lu_name_, 'Query_Artifact_API', 'Check_Query_Published');
IF Get_Published(query_) != 'True' THEN
ERROR_SYS.Appl_General(lu_name_, 'QUERY_NOT_PUBLISHED: Query :P1 is not Published.', query_);
END IF;
END Check_Query_Published;

Analysis:

It appears that the publication status is handled as a VARCHAR2 value and is language-dependent. This leads to inconsistent behavior depending on the session language.

Expected behavior:

The publication check should be language-independent. For example:

  • Either by using a language-neutral value internally (e.g., 'TRUE' regardless of session language), or
  • By relying on a strictly typed boolean mechanism rather than string comparison.

Impact:

  • Prevents adding valid queries as projection entities when using non-English languages
  • Difficult to diagnose without access to backend debugging tools
  • May affect other users working in localized environments

Request:

Could you please confirm whether this behavior is known and if a fix or workaround is available?
If not, it may be worth considering making this validation language-independent to ensure consistent behavior across different locales.

Thank you for your support.

Kind regards,

Guillaume