Skip to main content

Directions EMEA 2022: Questions

Introduction # Recently I had the pleasure of attending Directions EMEA 2022 in Hamburg, likely the largest conference in the Business Central sphere. Having only been at Days of Knowledge previously, the ~3000 attendees shows how impressive our community is. At Microsoft, we have internal usage numbers which show impressive usage, however the gravity of our product can sometimes be forgotten. So, seeing the keynote fill a 3000-person room does an amazing job conveying the importance of what we work on.

Transactions and Locking

Introduction # AL in fundamentally a single-threaded language and as a consequence there is no support for shared data in-memory, leaving the need for traditional synchronization primitives unnecessary. Instead, the synchronization of shared data is delegated to the database. The capabilities supported by databases is, to some degree, reflected in AL. Operations are transactional in AL using commits and rollback from the database. Concurrency control, in form of enforcing exclusive or shared access, is controlled by the database, leaving the orchestration to AL ergo the runtime.

Benchmarking AL code

Introduction # Many a developer has likely wondered the cost of discrete primitives in their language, e.g., what does an assignment cost in C# or AL? With normal programming languages these costs are relatively well defined since they often map directly down to assembly instructions with ‘simple‘ costing models. Further researchers are doing independent measurements on the timings of assembly instructions, see e.g., Agner Fog’s 4. Instruction tables which is by many considered the gold standard source on measurements of instructions on various hardware architectures.

Partial Records: Interlude

Introduction # Frequent feedback that we, as platform developers, receive is to include more code examples in our documentation. I wonder if it comes from the old academic adage of reading papers by reading the abstract; skimming the introduction, figures, and results or maybe the fancy code listing box catches the eye first. Nevertheless, I will abuse it in this post, having many code listings containing code examples. This post was originally meant to be a “down and dirty” look in the platform’s engine room, exploring how Partial Records makes data fetching faster.

Partial Records: Part 1

Introduction # Previously on this blog the Record type was presented and explored. In that post it was pointed out that the Record type and its accompanying API is large enough to warrant Directions sessions (and blog posts) for merely subsets of it. That was written with great confidence since I did so in our technical presentation on Partial Records at Directions. Having led the development and design of Partial Records I will allow myself some praise: The post will cover the history of Partial Records and show how it came to be.

On Records

Warning: Most of the article discusses implementation details for which we reserve the right to alter at any given point. Simplifications has been made for the sake of brevity and finally no guarantees are established by this article. Introduction # The record type is arguably the most important data type in AL development, one can hardly imagine AL development without it. Furthermore, with its inherent use in reports and pages it leaves no doubt about its fundamental status.


A blog with the goal of demystifying the behaviors of Business Central and its accompanying programming language AL. While it won’t teach you AL or show you great patterns of writing AL, hopefully through a better understand of AL and the runtime one will oneself become better at writing AL. The blog is conceptually inspired by SQL Server Internals and Windows Internals which are crucial assets for developers who wish to fully understand the platform which they develop on.