Skip to main content

SetLoadFields, for your Consideration!

Nice little feature in AL when thinking about performance is SetLoadFields Function. It sets the fields to be initially loaded when the record is retrieved from database, meaning that for example if you do define Item.SetLoadFields(Description) only Description Field will be retrieved from the database along with the fields that always selected for loading: Primary key, SystemId, and data audit fields SystemCreatedAt, SystemCreatedBy, SystemModifiedAt, SystemModifiedBy, fields that are filtered upon, and all other fields will be unloaded.

 


Also, a good method to use is SetBaseLoadFields(), that will omit loading of fields that are coming from table extensions so, you have only fields that are from base table to work with, not worrying about how many extensions are installed and lowering performance of your own code for which extensions are usually irrelevant.

And now comes the “Be careful” part if you in want to use “Description 2” for example in your later process you will receive nice little warning/error (depending how you setup your CodeCop alert) that using a “Description 2” field will cause a JIT load.

 


And this is one thing you should be careful about since every unloaded field will cause JIT load (Just-in-time loading). The platform, in such a case, does an implicit Get on the record and loads the missing field. Get calls can often be served by the server's data cache or can be resolved as a clustered index operation on the database, nevertheless they are one more call that you should avoid in order to have the best performance.

JIT load may also fail for multiple reasons, like:

The record has been modified between the original load and the subsequent JIT load.

The record has been deleted between the original load and the subsequent JIT load.

The record has been renamed between the original load and the subsequent JIT load.

One more thing you should care about is passing a partially loaded record as a function parameter, since CodeCop does not look for the JIT load outside of the scope of the function, be very careful not to cause JIT load when passing Partial Record as a parameter. Since this will cause a JIT load and lower the performance.

Example:

 

In summary, the SetLoadFields and SetBaseLoadFields functions in AL provide efficient ways to manage field loading and optimize performance. Selectively loading only necessary fields and excluding table extension fields enhances overall efficiency. However, caution is required to avoid JIT loads, as they may introduce potential risks and impact performance. Developers should be mindful when passing partially loaded records as parameters to maintain optimal AL development performance. 

Comments

Popular posts from this blog

How to? Integrate into new posting routine V19 – Businesses central.

Since V19 Microsoft has introduced a new posting interface. Depending how you concepted your integration in to a posting routine you might have to refactor your code. Let’s start by looking into what has changed. What we have now from Microsoft is a codeunit 825 "Sales Post Invoice Events" in this codeunit you can find a bunch of publishers that will enable you to integrate into a function from codeunit 80 (for newbies this is the codeunit that handles posting in Sales transferring Sales Order to a Posted Sales Invoice for example). To integrate your logic into posting for any new application you are developing you can use these publishers and find a specific point that suits you the most. Alternatively, you can implement interface "Invoice Posting" if it suits you better. Another change is that the table 49 "Invoice Post. Buffer" is discontinued. Yap! A little bit about this table, in general it is a preparation table for the lines in order for them...

Prepare For Certification - MB-820: Microsoft Dynamics 365 Business Central Developer

And finally, after around 10 years there is a certification again for Business Central Developers. Since there is no official book there are few ways to prepare by using online resources. Do not take this exam for granted event the old one was not easy even for the experienced developers :D nevertheless I hope that following links will help you prepare as best as possible. Review the study guide: Study guide for Exam MB-820: Microsoft Dynamics 365 Business Central Developer | Microsoft Learn Complete the training: Course MB-820T00---A: Dynamics 365 Business Central Developer - Training | Microsoft Learn There are also instructor materials available on GitHub that you can access for free: MicrosoftLearning/MB-820-Business-Central-Developer-Certification (github.com) What can I say more happy preparation 😊

Does Pass by Value Work in Businesses Central AL?

 The difference between pass-by-reference and pass-by-value is that modifications made to arguments passed in by reference in the called function have effect in the calling function, whereas modifications made to arguments passed in by value in the called function cannot affect the calling function. And it’s like that in any programing language, right? Well, no not in every case with Businesses Central AL, using a Variant Data Type and Record Ref’s have a little bug. Let’s check it out. Let’s define a RecRef and assign it to a Sales Line table for example and create a function that accepts input parameter Passed by value of type Variant, you can also try with RecordRef. Note that SourceRecordRef and SourceFieldRef are local Variables. Assigning Field Ref and then reusing the SourceRecordRef again to get the Customer table will change input parameter to a customer even if it is passed by value. This will happen if the input parameter is RecordRef also. And in documentation it is sta...