Dynamics 365 Business Central: new features for performant code

In the training I’ve done to some partners last week, when talking about performances I shared an example of an extension with 3 features that I think are not so well known but that have a significant impact on how your code performs, expecially on a SaaS environment. That extension used the following features:

  • Partial record loading
  • Temporary Tables
  • QueryCategory

The Partial record capability is a new feature available starting from Dynamics 365 Business Central 2020 Wave 2 (v17) and I think it’s one of my top personal desiderata from years.

This feature permits you to load only the needed fields of a recordset (when accessing a data source) instead of loading the entire set of fields. This is particularly useful on reports and OData pages because you can avoid to do a SELECT * (plus JOINS with all the extension’s tables) and instead doing a SELECT of only the fields you need.

Now you can do something like:

procedure TestPartialRecord(): Decimal
        Item: Record Item;
        total: Decimal;
        Item.SetLoadFields(Item."Unit Cost");
        if item.FindSet() then
                total += item."Unit Cost";
            until Item.Next() = 0;

As you can see in the above sample, you can use SetLoadFields to set which fields you want to retrieve in your operation ad the next FindSet() will retrieve only those fields (without loading extra fields and loading fields that comes from tableextensions of the Item table).

If you try to access a field that was not set to be loaded, in this case the platform performs an implicit GET operation on the record and loads that missing field.

You should not use partial record loading if you’re doing operations like inserts, deletes or if you’re using temporary records because in this case it’s required that the record is fully loaded.

The second feature explained on that example was the usage of Temporary tables. The concept of temporary tables is the same as in the past: they’re a temporary variable that holds data, but its data is not stored in the database but held in memory until you close or deallocate the table (A temporary table reduces the load on both the network and the SQL database backend).

For creating a temporary table, you’ve essentially the following ways:

  • using a temporary record variable (like TempItem: Record “Item” temporary;)
  • setting the SourceTableTemporary property on a page to true
  • Setting the TableType property of a table to Temporary (finally!)

With Dynamics 365 Business Central v17 you can declare a table as temporary like in the following example:

table 50100 MyTable
  DataClassification = CustomerContent;
  TableType = Temporary;

The advantage of this way of declaration is that the table schema isn’t synchronized with the database and so it does not have restrictions on breaking schema changes.

The third feature present on that sample was the usage of the QueryCategory property. I think that this is quite hidden, but with this property you can now execute a query object from a page by defining a query in AL and then specifying that property by setting a comma-separated list of query categories that this object can support.

As an example, this is a query defined in AL:

query 50100 "Top 10 Customer for Sales SD"
    Caption = 'Top 10 Customer Sales SD';
    OrderBy = Descending(Sum_Sales_LCY);
    TopNumberOfRows = 10;
    QueryCategory = 'Item List', 'Customer List';

        dataitem(Cust_Ledger_Entry; "Cust. Ledger Entry")
            filter(Posting_Date; "Posting Date")
            column(Customer_No; "Customer No.")
            column(Sum_Sales_LCY; "Sales (LCY)")
                Method = Sum;

The result of this is that you can immediatly execute the query from the specified pages (like a SmartList):

These are small tips, but that can affect a lot the performances of your code. Please keep them in mind and start using them when needed. Loving this work on the performance side… 🙂


  1. In the past, we had to use the ‘temporary’ tag upon record variable definition to indicate a variable was temporary. Using the AA0073 rule (temp prefix required), it was clearly visible the variable referred to a temporary table.

    With the new TableType = Temporary., we are no longer forced to mark the record variable as temporary, although I would find it still usefull to get the AA0073 warning, if not prefixed by Temp. What’s your advice / opinion on this?


    1. Agree. We had a rule to prefix all the temporary table declarations as Temp. I think the AA0073 warning should be respected also for tables explicitly declared as temporary on the object itself.


  2. What would be your recommendation for simple ‘GET’ statements that read only a limited no. of fields (not part of heavy loops)? Does it make sense starting to apply a best practice adding a SetLoadFields, even for simple GET statements? E.g.

    Customer.SetLoadFields(No., Name); // Would this make any sense in the end.
    If Customer.Get(CustomerNo) Then


    1. Hi Frederic, yes it makes sense in my opinion. The underlying query is much more performant. It’s not recommended to use partial records only on a record that will do inserts, deletes, renames, transferfields, or copies to temporary records. All these operations require that all fields on the record are loaded, so you will not have big benefits in this cases.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.