Skip to main content

We have two validations in our model which are not completely clear to us:
-    Reference columns do not correspond with the key of the source table with a lookup
-    Reference columns do not correspond with the key of the source table with a detail
 


The first one seems to check for references with check_ref <> 1 and show_look_up = 1 and the count of reference columns is unequal to the count of primary key columns from the source table. 
We make sure our check_ref = 1 references matches with the primary key columns. But we specifically use the ‘GUI’ references (check_ref = 0) to fill additional info when going into a detail tab.
I.e.: The reference below will also fill the column domain (which is not a PK) but is needed for a task to upload documents when the detail screen is still empty.
 


Why does this validation only check for non-integrity references?
What is the purpose of this validation? Could something go wrong?
Are there better alternatives to accomplish what we want?
 

Hi @K.Bakkenes,

The look-up and detail validations do indeed only check for non-integrity references. The reason for this is that there is also a third validation, which covers the other situation and does check for references with integrity: “Reference columns do not correspond with the key of the source table in foreign key constraint”.


References with integrity will actually be applied to the database, which is not possible in this situation. Since this will result in an error during the upgrade, we gave this validation the severity ‘Error’.

The other two validations you mentioned are not applied on the database, so can only potentially result in unexpected behavior in the UI. For this reason, we gave these validations the severity ‘Warning’.

The purpose of these validations is always explained in the consequence:

  • Reference columns do not correspond with the key of the source table with a lookup
    • Consequence: The lookup can display double rows because the key is incorrect. This can lead to error messages.
  • Reference columns do not correspond with the key of the source table with a detail
    • Consequence: More details are displayed than fall under the master. 

Perhaps my answer to your first question already provides enough context now, but  if the consequences for these validations are still not clear enough, please let me know.

As these validations do not indicate a problem but a potential problem you are warned for, we've allowed approving them. If the non-integrity references you mentioned are working as intended, I see no problem in approving the validation messages.

Hi Jeroen,

thanks for your answer!
Till this moment we have no errors that are a result of these validations.
Because we create such references on purpose, we will analyze the ones we have and approve them.

Terms & ConditionsCookie settings