I did a merge from our production db to our test db, plus a restore of both iam and db itself, to have a clean slate and start over with the exact same data.
Yet when I do a creation now, on the test, I get these added checks everywhere, which result in errors.
They look like this:
alter table "relatie" add constraint "c_relatie_opmerking" check ("opmerking" in ('0', '1', '2', '3')) go
Opmerking is a varchar(5000) column, so obviously this will fail. But no one here has any idea why these get added. The live doesn’t have them.
To illustrate:
This is the production, with 5 constraints
this is the test with 11
I can not delete them, only add (nor would I want to manually delete them to be honest, because there are a lot)
Why doesn’t a merge and restore fix this problem?
Best answer by Jeroen van den Belt
Hi Phil,
These check constraints are automatically generated by the SF (via a meta CP originating from a Thinkwise base model), based on two characteristics of a domain:
Min/max value: If these are defined for the domain linked to the column, a check constraint will be generated to ensure that allowed values must fall within that range.
Elements: If the domain linked to the column has elements, the corresponding DB-values will also be included in a check constraint.
Could you check in TEST whether one of these two aspects has indeed been added? The corresponding trace might also provide more clarity. You could also analyze the actions in the merge session to see whether that explains where this data is coming from.
I hope this helps point you in the right direction.
These check constraints are automatically generated by the SF (via a meta CP originating from a Thinkwise base model), based on two characteristics of a domain:
Min/max value: If these are defined for the domain linked to the column, a check constraint will be generated to ensure that allowed values must fall within that range.
Elements: If the domain linked to the column has elements, the corresponding DB-values will also be included in a check constraint.
Could you check in TEST whether one of these two aspects has indeed been added? The corresponding trace might also provide more clarity. You could also analyze the actions in the merge session to see whether that explains where this data is coming from.
I hope this helps point you in the right direction.
Thank you Jeroen, it seems that yes indeed, the elements bit is where it went wrong. To use the examples of the screenshot, the memo domain had 4 elements in the test, but 0 in the production.
But I don’t really understand why my merge hasn’t deleted them when I told it to make my test the same as the production. Or is that something a merge session isn’t allowed to do?
Perhaps something occurred that caused these actions to be seen as new or not properly removed. That’s difficult to determine without having seen the merge session.
My advice would be to create a ticket in TCP and provide enough reproducible information for us to investigate. This should at least include a backup of the SF (a model export is not sufficient in this case) and the platform version you are using.
