Hey Erik, what’s up with Code fields?

In this video, I talk (with myself) about code fields, the history behind them and how they work.

https://youtu.be/X1GN2GC43OE

In this video, Erik explores a question frequently asked by newcomers to Business Central and AL development: What’s the deal with Code fields? At first glance, they look like uppercase Text fields — so why do they exist? Erik takes us on a fascinating history lesson back to Navision version 3 (1990!) to reveal the clever sorting trick that made Code fields essential, then brings us back to the present to explain why you should still use them today.

The Question Everyone Asks

When developers first encounter AL and Business Central, they inevitably notice the Code data type and wonder: “Isn’t this just a Text field that’s uppercase? Why do we have two types for text fields? If you really want uppercase, you can just validate and you’re done.”

It’s a fair question — but the answer requires a bit of history.

A History Lesson: Navision Version 3 (1990)

Code fields have been part of Navision (now Dynamics 365 Business Central) from the very beginning. Erik demonstrates this by opening Navision version 3 from 1990 — a 31-year-old piece of software. Looking at the “Supplier” table (what we now call Vendor), we can see familiar patterns:

  • Vendor Number — Code field, length 20
  • Name — Text field
  • Search Name — Code field
  • District, Department, Project — all Code fields

These are the same field types we use today. This truly is the grandfather of Business Central.

The Native Database Sorting Trick

Here’s where it gets interesting. In the old Navision supplier list, Erik creates records with numbers like 1, 2, 100, and 200. When viewing the sorted list, the results come out in numeric order: 1, 2, 100, 200 — not the alphanumeric order (1, 100, 2, 200) that you’d get in Business Central today.

How was this possible? This version of Navision ran on the native database (pre-SQL), and the native database understood Code fields natively. Here’s the trick:

For a 20-character Code field, the database actually stored 21 characters. The extra character at the front was a prefix that encoded the length of the numeric portion of the value. So:

  • 1 and 2 were prefixed with a character representing length 1
  • 100 and 200 were prefixed with a character representing length 3
  • Values containing letters received a prefix character after “9” in the character set

This prefix ensured that when the database sorted the field, shorter numeric values always came before longer ones, producing a natural numeric sort order.

The Real Name: Alpha Fields

Interestingly, “Code” wasn’t the original internal name for this data type. Erik shows a C header file from C/Front — a product that allowed developers to connect to the Navision server using C code. Looking at the raw data types defined in this header:

  • String
  • DateTime
  • Blob
  • Bool
  • Sign16 (short integer)
  • Sign32 (integer)
  • Char
  • Alpha — this is the Code field!

Behind the scenes, the Code field was called an Alpha field (short for alphanumeric). The C/Front header even included AlphaToString and StringToAlpha conversion functions to move between the two representations.

Recreating the Trick in Modern AL

To demonstrate how this prefix trick worked, Erik builds a small example. The table has two fields: a Primary key field (Text[20]) and a Display field (Text[19]) — note that Primary is intentionally one character longer than Display to accommodate the prefix character.

table 50132 "Code Table"
{
    fields
    {
        field(1; Primary; Text[20])
        { }
        field(2; Display; Text[19])
        {
            trigger OnValidate()
            begin
                Primary := ' ' + Display;
                Primary[1] := strlen(Display) + 48;
            end;
        }
    }
    keys
    {
        key(P; Primary)
        { }
    }
}

The OnValidate trigger on the Display field does two things:

  1. Prepends a space to the Display value and assigns it to Primary (making room for the prefix character)
  2. Sets the first character of Primary to the ASCII representation of the string’s length — adding 48 because ASCII character 48 is '0', so a length of 1 becomes '1', a length of 2 becomes '2', and so on

The page is a simple list that only shows the Display field:

page 50132 "Code Fields"
{
    ApplicationArea = All;
    Caption = 'Code Fields';
    PageType = List;
    SourceTable = "Code Table";
    UsageCategory = Administration;

    layout
    {
        area(content)
        {
            repeater(General)
            {
                field(Display; Rec.Display)
                {
                    ToolTip = 'Specifies the value of the Display field';
                    ApplicationArea = All;
                }
            }
        }
    }
}

After entering the values 1, 2, 10, 20, 100, and 200, the list sorts them correctly: 1, 2, 10, 20, 100, 200. Using the Page Inspector (Ctrl+Alt+F1) to view the raw table data reveals the secret: the Primary field stores values like 11, 12, 210, 220, 3100, 3200 — where the first character is the length prefix.

The SQL Migration Disruption

When Dynamics NAV switched from the native database to SQL Server, this clever sorting trick was lost. SQL Server doesn’t understand Code fields natively, so it performs standard alphanumeric sorting. This caused an uproar among users because suddenly the sorting was “totally out of whack” on many fields, reducing the usability of some Code fields. But that was the price of progress.

Code Fields Today: Uppercase and Trimmed

So what does a Code field do in modern Business Central? Two things:

  1. Uppercase — all characters are converted to uppercase
  2. Trimmed — both leading and trailing spaces are removed

Erik demonstrates the trimming behavior with a small code snippet in the page’s OnOpenPage trigger:

trigger OnOpenPage()
var
    T: Text;
    C: Code[10];
    PsudoCode: Text;
begin
    T := ' 1 ';
    C := T;
    PsudoCode := T.ToUpper().Trim();

    message('!%1! (%2)', PsudoCode, strlen(PsudoCode));
end;

When assigning the text value ' 1 ' (a digit surrounded by spaces) to a Code variable, the result is '1' with a string length of 1 — not 3. Both leading and trailing whitespace are stripped. In pseudo-code, a Code field assignment is equivalent to calling .ToUpper().Trim() on a Text value.

Why You Should Still Use Code Fields

Given that Code fields are now essentially just uppercase, trimmed Text fields, should you bother using them? Absolutely yes. Erik’s argument comes down to one word: intent.

  • Show intent — Using a Code field communicates to other developers and users what kind of data this field holds and how it behaves. It’s the same reason you use a Date type instead of a DateTime even though dates are stored as DateTimes internally.
  • Consistency — The entire Business Central application uses Code fields for identifiers and keys. Following this convention keeps your customizations consistent with the rest of the system.
  • Communication — When you define a field as Code, you signal to the world that this is an identifier-type field with specific behavioral expectations. Users and developers both understand what to expect.

Instead of creating “weird primary keys” using Text fields with manual trim and uppercase logic, use Code — it signals to users and to the rest of the development community exactly what kind of field it is and what behavior they can expect.

Conclusion

Code fields have a rich 30+ year history in the Navision/Business Central ecosystem. What began as an ingeniously designed “Alpha” data type with built-in numeric sorting capabilities in the native database has evolved into a simpler but still meaningful data type that enforces uppercase and trimming. While the native database sorting trick was lost in the migration to SQL Server, the Code data type remains an important tool for communicating developer intent and maintaining consistency across the Business Central platform. When in doubt, if you’re defining an identifier or key field — use Code.

Picture of hougaard

hougaard