Validate() - all tables / all fields / always

[Arthurvdv]

Validate() - all tables / all fields / always | YouTube

Based of this presentation on BC TechDays of 2024, where a diagnostic should be raised when a direct assignment is done instead of a validate.

Direct field assignment

SalesLine."Unit Price" := NewPrice;
SalesLine.Modify();

field assignment though Validate

SalesLine.Validate("Unit Price", NewPrice);
SalesLine.Modify();

I think there are no exceptions as @StefanMaron and @ChristianHovenbitzer have convincingly presented to us.
Then a comment or pragma needs to be set justifying skipping the validation of the field.

[guidorobben]

There is an exception. Dont do this on Temp tables. But sometimes you just have to set it and not validate it.

[Arthurvdv]

Fair point, maybe I should go the other way around on this and only include Normal table types 🤔

[ChristianHovenbitzer]

I would agree that temporary Record variables should be excluded, but fields on inherently temporary tables should definitely be included in this rule. There should be no side effects outside the table when designing temporary tables.

I would also argue that Normal tables should not be used as temporary tables, but that is beside the point.

[Arthurvdv]

Thanks @ChristianHovenbitzer I kinda made the wrong turn here I see now.

procedure MyProcedure()
var
    MyTable: Record MyTable;
    TempMyTable: Record MyTable temporary;
begin
    MyTable.MyField := 'My Value';     // Raise diagnostic
    TempMyTable.MyField := 'My Value'; // Do not raise diagnostic
end;

We going to suppress the diagnostic on the TempMyTable variable, as this is a variable Is set as temporary and allowed to circumvent the triggers by assigning the value direct to the field without using validate.

[fvet]

Another exception might be when using ChangeCompany on the record variable. We avoid validate statements / table triggers when using ChangeCompany (which we tried to avoid for new dev, but is often used in legacy code)

[Arthurvdv]

Dammit, you’re right 😅

Even though I’m personally not a big fan of write operations after a ChangeCompany, I do understand there are valid use cases where you’d want to suppress this validation.

The tricky part is that this makes the rule significantly more complex to implement properly, as I’d need to follow the full code path to determine whether a ChangeCompany was involved. That can quickly become challenging across functions and especially between extensions.

Would using a pragma on the lines (or maybe the procedure itself) in those cases be an acceptable approach?

[StefanMaron]

I would go so far and say writing to a different company should never be done for this very reason.

Why not just start a session in the target company, and read from the original company. Then validate in target company can be used normally

[fvet]

I agree on not adding more complexity for these few (legacy) exceptions. Pragma'ing those cases would be sufficient ... or as Stefan mention, refactoring the StartSession might be a valid workaround as well.

[Arthurvdv]

The new Use Validate() instead of direct field assignment (PC0037) rule is now available in ALCops 0.9.0.