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
A question I get a lot – especially from people that come from C/AL, and only take their first steps into AL – is: How do I get to Microsoft’s source code of the BaseApp (and other)?
Well, there are multiple ways, really. You can download symbols, and unpack the symbols. You can download the DVD and get to the code on the DVD, or…
In this video I show how to add code analyzer to a Microsoft Dynamics 365 Business Central AL project and then activate them before dealing with all issues found:
In this video I show an example of how to reuse old NAV code in Microsoft Dynamics 365 Business Central.
This is the second part of the blog post “Organizing Code for a Seamless Transition from C/AL to Extensions in AL”, where we walk you through some of the steps you can take to organize the code in the existing C/AL coding language before the transition.
Since Business Central 2019 release wave 2 (version 15), the application has become completely AL-based. All functionality that modifies standard business logic must be moved into an Extension. This change influences how upgrades are performed and impacts all the solutions that are still in C/AL, making Dynamics partners consider transitioning to Extensions in AL
Let’s talk about the performance of the test code that we write for Business Central. What do I mean by “performance” and how can we improve it?
Defining “Performance”
Obviously, before we set out to improve something we need to have an idea of what it is we’re trying to optimise for. I’m coming to think of the performance of test code in a couple of key ways: