PlatformCop on ALCops

FlowFields should not be editable (PC0001)

Mon, 01 Jan 0001 00:00:00 +0000

FlowFields are calculated fields. Their values come from other data, and they are never stored directly on the record. In almost every case, a FlowField should not be editable, so set Editable = false. If you leave the property out, the field becomes editable by default.

When a FlowField is editable, the UI allows the user to type something into the field even though the value is calculated. The platform does not validate, store, or pass that input anywhere on its own. If your design requires users to enter a value in a calculated field, you must supply the logic that interprets and saves that input. Without that logic, whatever the user enters is ignored, which leads to confusion.

AutoIncrement in temporary table (PC0002)

Mon, 01 Jan 0001 00:00:00 +0000

The AutoIncrement property should not be used on fields in temporary tables. AutoIncrement is designed to generate unique values from the database sequence, which does not apply to temporary tables that only exist in memory.

Using AutoIncrement on a temporary table field is misleading and may not behave as expected.

Example

The following temporary table incorrectly uses AutoIncrement:

table 50100 MyTempTable
{
 TableType = Temporary;

 fields
 {
 field(1; EntryNo; Integer)
 {
 AutoIncrement = true; // AutoIncrement in temporary table [PC0002]
 }
 }
}

To fix this, manage the ID manually for temporary tables:

SetRange with filter operators (PC0003)

Mon, 01 Jan 0001 00:00:00 +0000

The SetRange method expects exact values, not filter expressions. If you pass a string containing filter operators (like *, .., |) to SetRange, they will be treated as literal characters, not as wildcards or operators.

Use SetFilter instead when you need to apply filter expressions with operators.

A code fix is available for this diagnostic.

Example

The following code incorrectly uses SetRange with a filter expression:

codeunit 50100 MyCodeunit
{
 procedure FindCustomers()
 var
 Customer: Record Customer;
 begin
 Customer.SetRange(Name, 'A*'); // SetRange with filter operators [PC0003]
 Customer.FindSet();
 end;
}

To fix this, use SetFilter for filter expressions:

List objects are one-based (PC0004)

Mon, 01 Jan 0001 00:00:00 +0000

List and Dictionary collections in AL use one-based indexing, not zero-based. Attempting to access index 0 will result in a runtime error.

Example

The following code incorrectly uses zero-based indexing:

codeunit 50100 MyCodeunit
{
 procedure ProcessList()
 var
 MyList: List of [Text];
 Value: Text;
 begin
 MyList.Add('First');
 Value := MyList.Get(0); // List objects are one-based [PC0004]
 end;
}

To fix this, use one-based indexing:

codeunit 50100 MyCodeunit
{
 procedure ProcessList()
 var
 MyList: List of [Text];
 Value: Text;
 begin
 MyList.Add('First');
 Value := MyList.Get(1);
 end;
}

Extensible property explicitly set (PC0005)

Mon, 01 Jan 0001 00:00:00 +0000

Tables, enums, and other extensible objects should explicitly set the Extensible property to declare whether the object can be extended by other apps. Relying on the default value makes the design intent unclear.

A code fix is available for this diagnostic.

Example

The following enum does not explicitly set Extensible:

enum 50100 MyEnum // Extensible property explicitly set [PC0005]
{
 value(0; Value1) { }
 value(1; Value2) { }
}

To fix this, explicitly set the Extensible property:

Access property explicitly set (PC0006)

Mon, 01 Jan 0001 00:00:00 +0000

Objects that can be accessed from other apps should explicitly set the Access property to declare their visibility. This makes the API surface of your extension clear and intentional.

Example

The following codeunit does not explicitly set Access:

codeunit 50100 MyCodeunit // Access property explicitly set [PC0006]
{
}

To fix this, explicitly set the Access property:

codeunit 50100 MyCodeunit
{
 Access = Public;
}

AutoCalcFields only on FlowFields (PC0007)

Mon, 01 Jan 0001 00:00:00 +0000

The AutoCalcFields parameter in Get, Find, and other record methods should only specify FlowFields. Including normal fields in AutoCalcFields has no effect and indicates a misunderstanding of the API.

Example

The following code incorrectly includes a normal field in AutoCalcFields:

codeunit 50100 MyCodeunit
{
 procedure GetCustomer()
 var
 Customer: Record Customer;
 begin
 Customer.Get('10000', Customer.Name); // AutoCalcFields only on FlowFields [PC0007]
 end;
}

To fix this, only specify FlowFields:

codeunit 50100 MyCodeunit
{
 procedure GetCustomer()
 var
 Customer: Record Customer;
 begin
 Customer.SetAutoCalcFields(Balance);
 Customer.Get('10000');
 end;
}

Operator and placeholder in filter expression (PC0008)

Mon, 01 Jan 0001 00:00:00 +0000

When using SetFilter with placeholders (%1, %2, etc.), be careful about combining operators in the format string with placeholder values. The operators should typically be in the format string, not in the placeholder values.

A code fix is available for this diagnostic.

Example

The following code has operators mixed with placeholders incorrectly:

codeunit 50100 MyCodeunit
{
 procedure FilterCustomers()
 var
 Customer: Record Customer;
 begin
 Customer.SetFilter("No.", '%1|%2', '10000', '20000'); // Correct usage
 Customer.SetFilter("No.", '>%1', '10000'); // Correct usage
 end;
}

EventSubscriber var keyword (PC0010)

Mon, 01 Jan 0001 00:00:00 +0000

Parameters in event subscriber procedures should use the var keyword when the event publisher declares them as var. Mismatching the var keyword can lead to unexpected behavior where modifications to parameters are not propagated correctly.

A code fix is available for this diagnostic.

Example

The following event subscriber is missing the var keyword:

codeunit 50100 MyCodeunit
{
 [EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", 'OnBeforePostSalesDoc', '', false, false)]
 local procedure OnBeforePostSalesDoc(SalesHeader: Record "Sales Header") // EventSubscriber var keyword [PC0010]
 begin
 end;
}

To fix this, add the var keyword to match the publisher:

EventPublisher IsHandled by var (PC0011)

Mon, 01 Jan 0001 00:00:00 +0000

When publishing events with an IsHandled pattern, the IsHandled parameter must be declared as var so that subscribers can set it to true to indicate the event was handled.

A code fix is available for this diagnostic.

Example

The following event publisher has IsHandled without var:

codeunit 50100 MyCodeunit
{
 [IntegrationEvent(false, false)]
 local procedure OnBeforeProcess(IsHandled: Boolean) // EventPublisher IsHandled by var [PC0011]
 begin
 end;
}

To fix this, add the var keyword:

FlowFilter field assignment (PC0012)

Mon, 01 Jan 0001 00:00:00 +0000

FlowFilter fields should not be assigned values directly. They are meant to be set using SetFilter or SetRange to filter the calculated FlowField values. Direct assignment has no effect and indicates a misunderstanding of the FlowFilter concept.

Example

The following code incorrectly assigns a value to a FlowFilter:

codeunit 50100 MyCodeunit
{
 procedure SetDateFilter()
 var
 Customer: Record Customer;
 begin
 Customer."Date Filter" := WorkDate(); // FlowFilter field assignment [PC0012]
 end;
}

To fix this, use SetRange or SetFilter:

Record.Get procedure arguments (PC0013)

Mon, 01 Jan 0001 00:00:00 +0000

Validates that calls to the Get procedure on Record objects use the correct number, types, and order of arguments matching the table’s primary key. Providing insufficient arguments, too many arguments, or arguments of the wrong type can cause runtime errors or unexpected behavior.

Example

procedure GetItemVariant()
var
 ItemVariant: Record "Item Variant";
begin
 // Invalid arguments in .Get() method for record "Item Variant": Insufficient arguments provided; expected 2 arguments.
 ItemVariant.Get('10000');
end;

procedure GetSalesHeader(DocumentId: Integer)
var
 SalesHeader: Record "Sales Header";
begin
 // Invalid arguments in .Get() method for record "Sales Header": Argument at position 2 has an invalid type; expected 'Code[20]', found 'Integer'.
 SalesHeader.Get("Sales Document Type"::Order, DocumentId);
end;

procedure GetCompanyInformation()
var
 CompanyInformation: Record "Company Information";
begin
 // Invalid arguments in .Get() method for record "Company Information": Too many arguments provided; expected 1 arguments.
 CompanyInformation.Get('', 12345);
end;

Exceptions

procedure GetCompanyInformation()
var
 CompanyInformation: Record "Company Information";
begin
 // If a table has one single Primary Key field of type Code, it's probably a setup table with the Singleton pattern, where we allow a GET without parameters
 CompanyInformation.Get();
end;

procedure GetItemVariant(MyRecordId: RecordId)
var
 ItemVariant: Record "Item Variant";
begin
 // RecordId object is populated on runtime, no diagnostics executed
 ItemVariant.Get(MyRecordId);
end;

Implicit conversions

During analyzing the correct type of the argument, the following implicit conversions are allowed;

JsonToken JPath uses double quotes (PC0014)

Mon, 01 Jan 0001 00:00:00 +0000

When using JPath expressions to query JSON, string values within the path should use double quotes, not single quotes. Single quotes in JPath expressions may not work correctly.

A code fix is available for this diagnostic.

Example

The following code uses single quotes in JPath:

codeunit 50100 MyCodeunit
{
 procedure ReadJson()
 var
 JsonObject: JsonObject;
 JsonToken: JsonToken;
 begin
 JsonObject.SelectToken('$[?(@.name==''John'')]', JsonToken); // JsonToken JPath uses double quotes [PC0014]
 end;
}

To fix this, use double quotes:

Guid empty string comparison (PC0015)

Mon, 01 Jan 0001 00:00:00 +0000

When checking if a Guid is empty, do not compare it to an empty string. Use IsNullGuid() instead, or compare against a Guid variable initialized to the empty Guid value.

A code fix is available for this diagnostic.

Example

The following code incorrectly compares a Guid to an empty string:

codeunit 50100 MyCodeunit
{
 procedure CheckGuid(MyGuid: Guid)
 begin
 if Format(MyGuid) = '' then // Guid empty string comparison [PC0015]
 Error('Guid is empty');
 end;
}

To fix this, use IsNullGuid:

Clear codeunit SingleInstance (PC0016)

Mon, 01 Jan 0001 00:00:00 +0000

Calling Clear on a SingleInstance codeunit clears the instance’s state, which affects all code using that singleton throughout the session. This is often unintentional and can cause subtle bugs.

Example

The following code clears a SingleInstance codeunit:

codeunit 50100 MyCodeunit
{
 procedure ResetCache()
 var
 CacheMgmt: Codeunit "Cache Management"; // SingleInstance codeunit
 begin
 Clear(CacheMgmt); // Clear codeunit SingleInstance [PC0016]
 end;
}

Consider whether clearing the singleton is truly the intended behavior. If you need to reset specific state, provide explicit reset methods instead.

Page record argument mismatch (PC0017)

Mon, 01 Jan 0001 00:00:00 +0000

When calling Page.Run or Page.RunModal with a record variable, the record type must match the page’s SourceTable. Passing a record of a different type will result in a runtime error.

Example

The following code passes a mismatched record type:

codeunit 50100 MyCodeunit
{
 procedure ShowVendor()
 var
 Customer: Record Customer;
 begin
 Page.Run(Page::"Vendor Card", Customer); // Page record argument mismatch [PC0017]
 end;
}

To fix this, use the correct record type:

codeunit 50100 MyCodeunit
{
 procedure ShowVendor()
 var
 Vendor: Record Vendor;
 begin
 Page.Run(Page::"Vendor Card", Vendor);
 end;
}

Page record method requires SourceTable (PC0018)

Mon, 01 Jan 0001 00:00:00 +0000

Methods like SetRecord, GetRecord, and SetTableView can only be called on pages that have a SourceTable defined. Calling these methods on pages without a SourceTable will result in a runtime error.

Example

The following code calls SetRecord on a page without SourceTable:

codeunit 50100 MyCodeunit
{
 procedure ShowPage()
 var
 MyPage: Page "My Dialog Page";
 Customer: Record Customer;
 begin
 MyPage.SetRecord(Customer); // Page record method requires SourceTable [PC0018]
 MyPage.Run();
 end;
}

Ensure the target page has a SourceTable, or use a different approach for pages without one.

Filter string single quote escaping (PC0019)

Mon, 01 Jan 0001 00:00:00 +0000

When using filter strings that contain single quotes, the quotes must be properly escaped by doubling them. An unescaped single quote will cause the filter to fail or behave unexpectedly.

A code fix is available for this diagnostic.

Example

The following code has an unescaped single quote:

codeunit 50100 MyCodeunit
{
 procedure FilterByName()
 var
 Customer: Record Customer;
 begin
 Customer.SetFilter(Name, 'O''Brien'); // Correct - escaped quote
 Customer.SetFilter(Name, 'O'Brien'); // Filter string single quote escaping [PC0019]
 end;
}

To fix this, escape single quotes by doubling them:

TransferFields type mismatch (PC0020)

Mon, 01 Jan 0001 00:00:00 +0000

When using TransferFields between two records, fields with matching names but different types will not be transferred and may cause unexpected data loss. This rule identifies potential type mismatches.

Example

If you have two tables with a field named “Amount” but one is Decimal and the other is Integer, TransferFields will not copy that field:

codeunit 50100 MyCodeunit
{
 procedure CopyRecord()
 var
 SourceRec: Record SourceTable;
 TargetRec: Record TargetTable;
 begin
 TargetRec.TransferFields(SourceRec); // TransferFields type mismatch [PC0020] - Amount field has different types
 end;
}

Review the field definitions and consider manually assigning mismatched fields with appropriate conversion.

TransferFields name mismatch (PC0021)

Mon, 01 Jan 0001 00:00:00 +0000

TransferFields copies values between records based on field IDs, not field names. If fields have the same ID but different names, the values will be transferred even though the fields represent different concepts. This rule identifies potential name mismatches that may indicate unintended transfers.

Possible overflow assigning (PC0022)

Mon, 01 Jan 0001 00:00:00 +0000

When assigning a value from a longer text field to a shorter one, or from a larger numeric type to a smaller one, data may be truncated or overflow. This rule identifies potential overflow scenarios.

A code fix is available for this diagnostic.

Example

The following code may truncate data:

codeunit 50100 MyCodeunit
{
 procedure CopyName()
 var
 LongName: Text[100];
 ShortName: Text[20];
 begin
 LongName := 'This is a very long name that exceeds twenty characters';
 ShortName := LongName; // Possible overflow assigning [PC0022]
 end;
}

To fix this, use CopyStr to explicitly handle truncation:

IsHandled parameter assignment (PC0023)

Mon, 01 Jan 0001 00:00:00 +0000

In event subscriber procedures that implement the IsHandled pattern, the IsHandled parameter should only be set to true, never to false. Setting it to false would override decisions made by earlier subscribers.

Example

The following code incorrectly sets IsHandled to false:

codeunit 50100 MyCodeunit
{
 [EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", 'OnBeforePostSalesDoc', '', false, false)]
 local procedure OnBeforePostSalesDoc(var IsHandled: Boolean)
 begin
 IsHandled := false; // IsHandled parameter assignment [PC0023]
 end;
}

To fix this, only set IsHandled to true when handling the event:

ApplicationArea on API page (PC0024)

Mon, 01 Jan 0001 00:00:00 +0000

API pages should not have ApplicationArea properties set, as they are not displayed in the UI and the ApplicationArea concept does not apply to API access.

A code fix is available for this diagnostic.

Example

The following API page incorrectly sets ApplicationArea:

page 50100 "My API Page"
{
 PageType = API;
 ApplicationArea = All; // ApplicationArea on API page [PC0024]

 layout
 {
 area(Content)
 {
 field(name; Rec.Name)
 {
 ApplicationArea = All; // ApplicationArea on API page [PC0024]
 }
 }
 }
}

To fix this, remove the ApplicationArea properties:

ODataKeyFields should use SystemId (PC0025)

Mon, 01 Jan 0001 00:00:00 +0000

API pages should use SystemId as the ODataKeyFields for consistent and reliable record identification. Using custom fields as keys can lead to issues when records are modified or when the key values contain special characters.

Example

The following API page uses a custom key:

page 50100 "My API Page"
{
 PageType = API;
 ODataKeyFields = "No."; // ODataKeyFields should use SystemId [PC0025]
 SourceTable = Customer;
}

To fix this, use SystemId:

Mandatory field missing on API page (PC0026)

Mon, 01 Jan 0001 00:00:00 +0000

API pages should expose certain mandatory fields like SystemId, SystemCreatedAt, SystemCreatedBy, SystemModifiedAt, and SystemModifiedBy. These fields are important for API consumers to track record metadata.

A code fix is available for this diagnostic.

Example

The following API page is missing mandatory fields:

page 50100 "My API Page"
{
 PageType = API;
 SourceTable = Customer; // Mandatory field missing on API page [PC0026]

 layout
 {
 area(Content)
 {
 field(name; Rec.Name) { }
 }
 }
}

To fix this, add the mandatory system fields:

Temporary record trigger invocation (PC0027)

Mon, 01 Jan 0001 00:00:00 +0000

Calling Insert, Modify, or Delete with RunTrigger = true on a temporary record will not execute database triggers because temporary records are not persisted. This is often unintentional and can lead to missing business logic execution.

Example

The following code runs triggers on a temporary record:

codeunit 50100 MyCodeunit
{
 procedure CreateTempRecord()
 var
 TempCustomer: Record Customer temporary;
 begin
 TempCustomer.Init();
 TempCustomer."No." := 'TEMP001';
 TempCustomer.Insert(true); // Temporary record trigger invocation [PC0027]
 end;
}

Consider whether triggers should be invoked. For temporary records, typically use:

TableRelation field length (PC0028)

Mon, 01 Jan 0001 00:00:00 +0000

When defining a TableRelation, the field lengths should be compatible. A relation from a longer field to a shorter one, or vice versa, may cause data integrity issues or runtime errors.

Example

The following code has mismatched field lengths:

table 50100 MyTable
{
 fields
 {
 field(1; CustomerNo; Code[30]) // TableRelation field length [PC0028]
 {
 TableRelation = Customer."No."; // Customer.No is Code[20]
 }
 }
}

To fix this, ensure field lengths match:

PlatformCop on ALCops

FlowFields should not be editable (PC0001)

AutoIncrement in temporary table (PC0002)

Example

SetRange with filter operators (PC0003)

Example

List objects are one-based (PC0004)

Example

Extensible property explicitly set (PC0005)

Example

Access property explicitly set (PC0006)

Example

AutoCalcFields only on FlowFields (PC0007)

Example

Operator and placeholder in filter expression (PC0008)

Example

EventSubscriber var keyword (PC0010)

Example

EventPublisher IsHandled by var (PC0011)

Example

FlowFilter field assignment (PC0012)

Example

Record.Get procedure arguments (PC0013)

Example

Exceptions

Implicit conversions

JsonToken JPath uses double quotes (PC0014)

Example

Guid empty string comparison (PC0015)

Example

Clear codeunit SingleInstance (PC0016)

Example

Page record argument mismatch (PC0017)

Example

Page record method requires SourceTable (PC0018)

Example

Filter string single quote escaping (PC0019)

Example

TransferFields type mismatch (PC0020)

Example

TransferFields name mismatch (PC0021)

See also

Possible overflow assigning (PC0022)

Example

IsHandled parameter assignment (PC0023)

Example

ApplicationArea on API page (PC0024)

Example

ODataKeyFields should use SystemId (PC0025)

Example

Mandatory field missing on API page (PC0026)

Example

Temporary record trigger invocation (PC0027)

Example

TableRelation field length (PC0028)

Example