Validate field length against TableRelation

[fvet]

We would like fields referencing master data / other tables to inherit at least the (same datatype? and) minimum field length as the referenced / parent table.

BAD CODE

field(1; "Customer No."; Code[10])   <<< Code 10 is less than the Customer."No." field length
{
            Caption = 'Customer No.';          
            TableRelation = Customer;
}

GOOD CODE

field(1; "Customer No."; Code[20])  <<< Code 20 matches the Customer."No." field length
{
            Caption = 'Customer No.';          
            TableRelation = Customer;
}

ALSO GOOD CODE

field(1; "Customer No."; Code[30])   <<< We've some scenarios where longer values are accepted
{
            Caption = 'Customer No.';          
            TableRelation = Customer;
            ValidateTableRelation = false;
}

---

Copied from microsoft/AL#4493
Is your feature request related to a problem? Please describe.
If a new field is created, having a table relation, the field datatype/length is set. If the related table definition is changed, e.g. increase of related (key) field length from code 10 to code 20, the fields having a table relation should be increased as well.

Describe the solution you'd like
Have a new CodeCop rule that checks any field having a TableRelation to match at least the MINIMUM length of the related field (cfr. test codeunit 134926 Table Relation Test)

Describe alternatives you've considered
Running test codeunit 134926 Table Relation Test instead.
However, the codeunit sometimes fails, since we have fields - with a tablerelation - that are longer than the related field.

[StefanMaron]

But why would you have a flow field with larger field length?

[fvet]

@StefanMaron It's not about flowfields, it's about 'TableRelation' (combined with ValidateTableRelation = false).

We could imagine a field with TableRelation = Customer that allows user to set a 'Customer Filter':

1. Code[10] would be wrong (overflow).
2. Code[20], I can add a customer no.
3. Code[50] (combined with ValidateTableRelation = false) : would allow be to manually fill 'CUSTOMERA|CUSTOMERB'. We'd still add the

TableRelation to support 99% of the case where the customer fills just one value, but with ValidateTableRelation = false and large field lengths, we allow the user to fill in other / longer values.

Case 3 is rather an exception and I can perfectly live with these by adding a pragma warning on the new linter cop rule.

Rule should focus on fields having a table relation and a deviating field definition (datatype / length) from the table relations PK.

[StefanMaron]

Sorry, I meant table relations. But I get it. Could be also combined with ValidateTableRelation if it is not set to false then it should have the exact lenght?

[fvet]

@StefanMaron Updated my comments in the meanwhile

Case 3 is rather an exception and I can perfectly live with these by adding a pragma warning on the new linter cop rule.

Rule should focus on fields having a table relation and a deviating field definition (datatype / length) from the table relations PK.

[fvet]

@Arthurvdv With the new LC0051 rule in place, I by accident discovered some incorrect field definitions on some of our tables. However, I can't remember if above request / rule has been implemented by either BCLintercop or by MS. None of the cops raise any warnings for below fields. I would have expected to get a warning on mismatching fields definitions....

[fvet]

@Arthurvdv Seems to be one of the rules with quit some votes. Any chance on squeezing this one in for the next release? :)

[Arthurvdv]

I'll see what I can do!

..but to be honest, I believe this should be part of one of the CodeCops provided from Microsoft.

84 votes seems that there's enough demand for this 🤔

I would suggest we raise this again with a new issue on Microsoft github and refer with the BC idea with the amount of votes. Do you agree?

[fvet]

The original idea already had 84 votes and got declined (asking to use github instead).
I won't spend time raising votes again and wait another five years for MS to come up with some updates... :(

That's why I tried using the LinterCop way instead ;)
You will be a lot faster in providing the requested rule, I'm sure.