[Bug]: PC0030 false positive on setup tables using Get()

[DominicSaladin]

Analyzer

PlatformCop

Issue type

False positive (diagnostic fires when it shouldn't)

Rule ID

PC0030

Description

I like the new rule and it helps improve the performance. But as I can see it shows on setup tables too, which afaik shouldn't use SetLoadFields as there is no benefit of doing it.
Is there a way to exclude those without having to use pragma everywhere?

AL code to reproduce

var
      MarketingSetup: Record "Marketing Setup";
begin
      MarketingSetup.Get();

Additional context

No response

[Arthurvdv]

Analysis: SetLoadFields on Setup Tables

We investigated this and agree that PC0030 should not fire on setup table Get() calls. Here's what we found:

Microsoft's own practice

We analyzed the BaseApp source code:

Metric	Value
Setup.Get() calls in BaseApp	~2,977
With SetLoadFields before them	~54 (1.8%)

Microsoft does not use SetLoadFields on setup tables in 98% of cases. When they do (e.g., in DocumentNoVisibility.Codeunit.al), it's in specific UI-initialization paths where every millisecond matters. Their preferred optimization for setup tables is GetRecordOnce() (a session-level cache pattern), not partial records.

Why SetLoadFields has near-zero benefit on setup tables

Research from keytogoodcode.com (which tested with SQL Server statistics) shows that SetLoadFields's real SQL-level benefit is eliminating JOINs to table extension tables on large result sets. For a single-record Get() on a cached setup table, there is no measurable performance difference.

Additionally, alguidelines.dev's refactoring guide shows the "correct modernized version" of code with SalesSetup.Get() explicitly without SetLoadFields, treating this as acceptable.

Planned fix

We will suppress PC0030 when both conditions are met:

1. The read operation is a parameterless Get() (i.e., Setup.Get() with no arguments)
2. The table is detected as a setup table using the following heuristic:
   • Single primary key field
   • PK field type is Code
   • PK field name matches "Primary Key" or "PrimaryKey" (case-insensitive)

This heuristic covers all standard BC setup tables (General Ledger Setup, Sales & Receivables Setup, Marketing Setup, etc.) while avoiding false suppressions on tables like Currency or Country/Region that have a single Code PK but are multi-record tables called with Get('USD').

No pragma workarounds should be needed after this fix.

---

This analysis was AI-generated using research across Microsoft's BaseApp/BCApps/ALAppExtensions source code and community documentation.

[Arthurvdv]

Thank you for reporting this! I've resolved this with the release of version v0.8.3 of ALCops.

I'm going ahead and close the issue here, but feel free to reopen if it's not working as expected.