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...