Hi,

The validation takes into account all the application languages. Could it be that not in all languages the translations match the db value? You can also negate this validation by not adding it as a Sorting column for tables.

Hope this helps!

Hey Mark,

Thank you for the suggestion, but unfortunately the solution you provided did not fix the problem. (We do not have another application language, and disabling the validation by not adding it as a sorting column for tables is also not an option)

It seems like the issue is fixed based on the error message, but the validation stays.

Could you please provide more information or offer any other solutions?

This is the validation query (2023.1) in its core, you can look into the exists queries of it. Maybe there's a duplicate translation? From my position is it difficult to tell why the validation returns what it returns

declare @model_id model_id = ''
      , @branch_id branch_id = ''

select
    d.model_id as pk_col_1,
    d.branch_id as pk_col_2,
    d.dom_id   as pk_col_3
from dom d
where d.model_id = @model_id 
  and d.branch_id = @branch_id 
  and exists (
            select 1 
            from col c
            where c.model_id = d.model_id
              and c.branch_id = d.branch_id
              and c.dom_id = d.dom_id
              and c.sort_no is not null)
  and exists (
    select 1 from (
        -- Ordered by translation
        select e.elemnt_id, t.appl_lang_id, row_number() over(partition by t.appl_lang_id order by t.transl) as nr
        from elemnt e
        join transl_object_transl t
          on t.model_id = e.model_id
         and t.branch_id = e.branch_id
         and t.type_of_object = 2 --dom_elemnt
         and t.transl_object_id = e.elemnt_id
        where e.model_id = d.model_id 
          and e.branch_id = d.branch_id
          and e.dom_id = d.dom_id

        except
        -- Ordered by db value
        select e.elemnt_id, t.appl_lang_id, row_number() over(partition by t.appl_lang_id order by e.db_value)
        from elemnt e
        join transl_object_transl t
          on t.model_id = e.model_id
         and t.branch_id = e.branch_id
         and t.type_of_object = 2 --dom_elemnt
         and t.transl_object_id = e.elemnt_id
        where e.model_id = d.model_id 
          and e.branch_id = d.branch_id
          and e.dom_id = d.dom_id
    ) a
  )

(Replace model_id / branch_id with project_id / project_vrs_id in case of 2022.2 or older)

It does appear to be an error in the validation itself. The database values are of type tinyint and range from 0 – 10. Element ‘void_space’ here has db_value 10 which when ordered as an integer should be sorted to the bottom. The validation however sorts on the software factory column elemnt.db_value which is of type varchar(25). The value ‘10’ gets sorted before ‘2’ since these are strings and get sorted as such.

A cast to tinyint like shown below solves the problem. Perhaps this validation should cast the elemnt.db_value to the Data type defined by the user in the SF:
 

We’ll approve the validation for now since there doesn’t seem to be any problem with the domain.

Great find, that is indeed an issue. Can you create a ticket for this? We'll be sure to correct this.

Simply casting this to tinyint does solve this for this situation, but db_value is not necessarily a numeric value so a different solution would have to be implemented.