Hi Cyril,

Edit: It seems to be something else my colleague says, we are gathering some more information.

Hi Cyril,

The column ‘verified’ has indeed been renamed to ‘approval_status’ during the upgrade to the 2022.1. To support this change, we changed all occurrences of this term in the code accordingly. We also renamed the validations “Translation is unverified in elanguage]” to “Translation is not yet approved in ylanguage]”.

Having changed all occurrences of the old column name, also applies to the meta control procedure responsible for adding these validations. However, this meta control procedure is present in the Thinkwise base project named “VALIDATIONS”. Base projects are not imported into your work project until you generate definitions. Therefore, the old validations will not be removed, and the new validations containing the up-to-date code will not be added, until definitions have been generated.

Could this have been the case, that you did not generate definitions before validating? In some cases, it can be necessary to generation definitions twice after having upgraded your platform due too sequencing issues.

If you have any further questions, please let me know.

Hi Jeroen,

I tested it again, but yes, I did run the “Generate definition” first, and secondly did the “Validate definition”.

So..maybe we can check somewhere if the VALIDATIONS-project is correctly upgrade, or the VALIDATIONS base project is correctly updated during “Generate definition” ?

Hmm, that's a bit strange. I think indeed we need to have a closer look at this. Would you be so kind to create a TCP ticket, referring to this topic? Then we can handle the situation from there and provide you with the proper support.

Jeroen

I also had this error after the upgrade

Solved by executing this statement on the SF database, because in Validation code of these entries is the 'verified'-column still present.

DELETE FROM dbo.validation
WHERE validation_id LIKE 'val_unverified_transl%'

Afterwards, re-run the Execute all validations task and the error is gone.

@PatrickW Thanks for the addition, that should indeed do the trick in resolving this error.
I didn't mention this step myself yet, because I think it is important to first check if the new validations are present before removing the reproduction scenario for this error. Otherwise potentially undesired situations will not be validated.

@C. Lousberg I’ll leave it up to you if you want to perform these actions yourself and be done with it, or if you still want to submit a ticket so we can also investigate why this problem occurred in the first place.

 Checking the presence of the renamed validations can be done by executing this statement on your SF-database:

select *
from dbo.validation
where validation_id like 'val_transl_not_yet_approved_%'

@Jeroen van den Belt  just created the ticket to solve the issue also for other Thinkwise customers.

Also ran the query and validation_id "val_transl_not_yet_approved_eng” is present.

Thanks @PatrickW for the manual fix already! 

For the record, this issue persists with (current) downloads of 2023.1 packages after upgrading and multiple generation runs.

For the benefit of search engines, I add the code of the validation that triggered the error in my model, which includes the column transl_object_transl.verified, instead of transl_object_transl.approval_status

select v.validation_code
  from ont_sf_20231.dbo.validation as v
 where v.validation_id = 'val_unverified_transl_nl'

/* result */

-- Only add validation messages when translation review is required (as set in the Configuration screen under Settings)
if exists (select 1
           from sf_configuration
           where transl_review_required = 1)
begin
    insert into validation_msg
    (
        model_id,
        branch_id,
        validation_id,
        pk_col_1,
        pk_col_2,
        pk_col_3,
        pk_col_4,
        pk_col_5,
        pk_col_6,
        pk_col_7,
        generated,
        insert_user,
        insert_date_time,
        update_user,
        update_date_time    
    )
    select 
        @model_id,
        @branch_id,
        @validation_id,
        @model_id as pk_col_1,
        @branch_id as pk_col_2,
        t.type_of_object as pk_col_3,
        t.transl_object_id  as pk_col_4,
        t.appl_lang_id as pk_col_5,
        null as pk_col_6,
        null as pk_col_7,
        1,
        dbo.tsf_user(),
        sysdatetime(),
        dbo.tsf_user(),
        sysdatetime()
    from transl_object_transl t 
    where t.model_id = @model_id 
      and t.branch_id = @branch_id
      and t.appl_lang_id = 'NL'
      and t.verified = 0
      and t.transl not like 'e ]%'
end

Hi Boudewijn,

in the meanwhile I created a TCP ticket and after also sharing my SF-DB with Thinkwise, they decided it is not an issue on our SF as Thinkwise technicians are not able to reproduce it on our uploaded SF.
For us this is really strange as you are nr 3 mentioning the issue.

We tested it about 10 times this upgrade and everytime the issue occurs.

Now agreed with Thinikwise support to just run the DELETE-statement mentioned by @PatrickW as these records are not needed anymore.

So in our opinion there is something missing in the cleaning part of the upgrade script, but for some reason no error-message is triggered, and it doesn't occur in all situations….strange…..

Hi CL,

Thanks for your reply. It is strange indeed; the resolution is easy enough, but finding the cause for the validation error in the first place and deciding whether to delete the validation or not takes the bulk of the time.

With some luck others can find our conversation and cut some time on their research!