Skip to main content

I don't understand this validation. I have a table on which the primary key (1 column) is also used as look-up display value. This should be unique. The code like below illustrates it the best I think;

-- code generated by the SF;
create table dbo.[dummy]
(
   dummy_id            varchar(100) not null,
   dummy_description   varchar(500) null,
   tsf_valid_from     datetime2 (2) generated always as row start  hidden   not null  ,
   tsf_valid_to       datetime2 (2) generated always as row end    hidden   not null  ,
   constraint [dummy_pk] primary key clustered
   (
      dummy_id
   ),
   period for system_time (tsf_valid_from, tsf_valid_to)
)

go

insert into dummy (dummy_id) values ('Test'), ('Test') -- second insert will fail

I think the validation is in this case invalid?

What version of the SF are you using and can you show the reference that triggers this warning. 

We're using SF 2020.1 with hotfixes until 20201008. I've recently tested the upgrade to SF 2021.1 and in that database the validation seems to be disappeared there… I see some code differences in the validation code, I’d almost assume it's fixed by doing the upgrade. I think we should ignore the warning and wait for the upgrade.

I don't exactly understand what you mean by ‘the reference that triggers’ this warning. The related object of the validation points to the table:

 

Hi René,

We just discovered this question hasn't been resolved yet. Is this validation message still present?

My colleague means the reference that triggers this validation. This could be a reference between two tables or a self-reference. When we know the exact properties of the reference, then we can find out why this validation is giving you this warning.

It does look like the Related object does say the usr table is the source-table. Check it's references and see if any reference could potentially give double look-up values. 

Hi, I can't reproduce it anymore, I don't have the project anymore (it was in a sandbox environment I've cleaned up). As said it's probably solved when we upgraded to 2021.1.

Terms & ConditionsCookie settingsAccessibility statement