Key to Good Code

As a follow-up to my previous post , I'd like to linger a little longer on the topic of wide rows and the effects of row overflow in SQL Server, and specifically on the storage impact that we can observe in Business Central SaaS tenants when too many rows spill into the row overflow storage unit. Sample data and the first test The tests below that I'm going to run will be built around the following table with four text fields. table 50101 "Large Test Rec" { DataClassificati

The maximum size of a table row in SQL Server in limited to 8 KB, or to be more precise 8060 bytes, if we follow Microsoft online articles, such as Maximum Capacity Specifications for SQL Server - SQL Server | Microsoft Learn . This limit arises from the SQL Server data storage architecture: table rows are organized in 8-kilobyte pages, and a single row cannot exceed the size of the page, therefore 8KB is the maximum amount of storage space that can be allocated for a single

Recently, one particular piece of code in Business Central's codeunit 1501 Workflow Management once again revived the old discussion about the benefits of calling IsEmpty before actually retrieving the records with FindSet . Yes, that inexhaustible if not IsEmpty then FindSet . I already wrote about this a few times here and here . But this time the combination of IsEmpty with FindSet appeared to be a good pretext to talk about index efficiency: when a seemingly good index

Introduction of the SetLoadFields function in AL language that allowed to limit the number of fields returned to the Business Central...

Since the time when I came across this post by Waldo (or actually, he mentioned his test results in one online discussion) I was curious...

Back in the old Navision days, when clients' data were stored in the Navision native database instead of Azure SQL Server, and functions...

I once wrote a post on event subscribers and the presumed performance benefits of single instance subscriber codeunits, but the topic keeps reappearing every now and then, and I feel it could be a good idea to add a few more arguments to the same old debate. Because why not run a few useless, but highly entertaining tests on a Saturday evening. One statement in defense of the single instance event subscribers is that the subscriber codeunit does not have to be disposed after

Recently I heard an opinion shared by some AL developers that recursion in AL can be dangerous and should be avoided because the AL...

Recently I was debugging a very interesting deadlock case which I want to share in a blog post now. It was especially curious because, as...

It has been said so many times that filtering on FlowFields is bad for performance that we are used to avoiding this kind of filters in...