InDataSet, do we still need this?

Many NAV developers are still adding InDataSet attributes to lists, but is it needed anymore? Check out the video:

https://youtu.be/_lXesNywno4

In this video, Erik investigates whether the [InDataSet] attribute is still necessary in modern AL development for Business Central. Spoiler: it isn’t. The modern AL compiler is smart enough to figure out which variables belong in the dataset on its own.

The Origin of the Question

The inspiration for this investigation came from a discussion around some legacy code that originated from an older version of NAV. The code featured a List page with a bunch of global variables controlling style settings, visibility, and other display properties. All of these variables were decorated with the [InDataSet] attribute.

Erik had recently built a new data inspector for the toolbox — a component that shows various data in a single List page using a large number of columns that are toggled on and off to present the correct view. Throughout that entire development effort, he never used [InDataSet] — not even once. That prompted a conversation with some people at Microsoft, who confirmed that it likely isn’t needed anymore.

What Does [InDataSet] Do?

According to the official documentation (which was recently updated), [InDataSet] is described as follows:

Sets the variable’s value to be included in the dataset. The [InDataSet] attribute is for global variables of type Boolean or Integer. You must define this attribute on a variable if it is used as the value of the Editable, Enabled, Visible, or StyleExpr property.

In other words, if you have a global variable that controls the appearance or behavior of columns in a repeater, the documentation says you need [InDataSet] so that the variable is included in the data that gets sent to the client for each row.

Testing Without [InDataSet]

Erik set up a simple test using a customer list page. Here’s the code with the [InDataSet] attribute still in place:

page 50100 "Customer List 2"
{
    PageType = List;
    SourceTable = Customer;
    Caption = 'Customer List 2';

    layout
    {
        area(Content)
        {
            repeater(Rep)
            {

                field("No."; Rec."No.")
                {
                    ToolTip = 'Specifies the value of the No. field';
                    ApplicationArea = All;
                }
                field(Name; Rec.Name)
                {
                    ToolTip = 'Specifies the value of the Name field';
                    ApplicationArea = All;
                }
                field("Name 2"; Rec."Name 2")
                {
                    ToolTip = 'Specifies the value of the Name 2 field';
                    ApplicationArea = All;
                }
                field(AltAdr; AltAdr)
                {
                    ApplicationArea = all;
                    CAption = 'Alt Adr';
                }

            }
        }
    }
    trigger OnAfterGetRecord()
    begin
        AltAdr := Rec.Address;
    end;

    var
        [InDataSet]
        AltAdr: Text;
}

The page displays customer data with an additional column, AltAdr, which is a global variable populated in the OnAfterGetRecord trigger. Erik also tested with style expressions that conditionally set column formatting — for example, turning certain columns black when a specific name appeared.

He then removed the [InDataSet] attribute from both the style variable and the AltAdr variable, deployed the page, and everything continued to work exactly as before:

  • The style expressions still applied conditional formatting correctly.
  • The AltAdr global variable still displayed the correct address values for each row.
  • No errors, no missing data, no visual differences.

Why It No Longer Matters

Erik asked Microsoft directly, and the answer was straightforward: the new AL compiler is much more intelligent. It analyzes the code and automatically determines which variables are used to produce the dataset — that is, everything that goes into the repeater, including fields and the variables that control column properties like visibility and styling.

Because the compiler figures this out on its own, the [InDataSet] attribute has no practical effect anymore. It’s essentially a no-op.

The documentation describing the requirement was accurate at one point in time. In older versions of NAV and early Business Central runtimes, omitting [InDataSet] could produce very strange and unpredictable results. But with the modern compiler, that’s no longer the case.

Conclusion

The takeaway is simple: you don’t need [InDataSet] in modern AL development. The attribute has no effect — the compiler is smart enough to figure out which variables belong in the dataset without being told explicitly. If you encounter it in legacy code, you can safely remove it. And for new development, you can skip it entirely.

Picture of hougaard

hougaard