BigText variables are for dinosaurs

In this video, I talk and show why you shouldn’t use BigText variables anymore. BigText was the solution to the old 1000 character limitation of the Text type in NAV. Limitations that are long gone with Microsoft Dynamics 365 Business Central.

https://youtu.be/wMO4vynFw60

In this video, Erik explains why the BigText data type in Business Central is a relic of the past and why you should stop using it in new AL code. He walks through the historical reasons BigText existed, demonstrates its limitations compared to modern alternatives, and shows how Text and TextBuilder are superior replacements.

A Brief History of BigText

BigText was introduced way back in the early versions of Navision. At that time, the Text variable was limited to around 1,000 characters. If you needed to work with anything larger — and this was the era when XML was becoming prevalent, which meant dealing with lots of text — you had to get creative with arrays of text, streams, automation controllers, or other workarounds.

BigText solved this problem by providing the ability to convert between blobs and text, and to build up larger strings. It served a real purpose at the time.

Fast forward 10 or more versions, and BigText is still around. Erik still sees people using it, likely out of old habits. The purpose of this video is to make it clear: there is no good reason to use BigText in new code. It will give you more trouble than benefits.

The Demo Setup

Erik created a simple AL extension to demonstrate the different approaches. Here’s the complete code he walks through:

pageextension 50100 CustomerListExt extends "Customer List"
{
    trigger OnOpenPage();
    var
        BT: BigText;
        s: Text;
        TB: TextBuilder;
        InS: InStream;
        OutS: OutStream;
    begin
        BT.AddText('Erik');
        BT.AddText(' ');
        BT.AddText('Hougaard');
        s := 'Erik';
        s := s + ' ';
        s := s + 'Hougaard';

        BT.Read(InS);
        InS.Read(s);

        BT.Write(OutS);
        OutS.Write(s);

        TB.Append('Erik');
        TB.Append(' ');
        TB.Append('Hougaard');
        message(format(TB));
    end;
}

Reason 1: Building Up Strings — Use TextBuilder Instead

One common pattern with BigText is using AddText to concatenate strings together:

BT.AddText('Erik');
BT.AddText(' ');
BT.AddText('Hougaard');

Erik points out that this pattern is close to an anti-pattern at this point. Microsoft’s own documentation warns that doing this with many strings leads to poor performance, because BigText is backed by a string internally. Each time you add text, the system has to allocate new memory and copy the entire existing content into it.

The same problem exists with plain text concatenation:

s := 'Erik';
s := s + ' ';
s := s + 'Hougaard';

With each concatenation, the system allocates the first string, then grabs the existing string plus the new content and copies everything into a new memory location. For three lines this is immeasurable, but if you’re concatenating many strings — especially large ones — you can easily end up swapping hundreds of kilobytes of memory per operation.

The proper solution is the TextBuilder:

TB.Append('Erik');
TB.Append(' ');
TB.Append('Hougaard');
message(format(TB));

What TextBuilder does is fundamentally different. Instead of re-allocating and copying memory with each append, it allocates the three strings independently and essentially “ropes” them together. Some other programming languages refer to this as a rope data structure. The actual concatenation into a single string only happens when you call Format(TB) or convert it to text — as a single operation rather than repeated re-allocations.

Reason 2: Text Size — Text Is Just as Big

Another reason people reach for BigText is the assumption that it can hold more data than a regular Text variable. Erik argues this isn’t really the case anymore.

The BigText documentation states it can hold two billion characters, corresponding to two gigabytes. However, it also warns that BigText is backed by a .NET string, which has a maximum of approximately one billion characters (since each character is 16 bits, that works out to the same two-gigabyte .NET memory limit). Erik believes there’s actually a documentation inconsistency here, and the practical limits of Text and BigText are essentially the same.

If your reason for using BigText is size, there’s no advantage. A regular Text variable holds just as much, and it comes with all the standard string functions, can be passed to web services, and works seamlessly throughout the platform. With BigText, you’re reduced to just a handful of functions.

Reason 3: Stream Integration — Streams Work with Text Too

The third reason Erik has seen people use BigText is for its Read and Write functions connected to streams:

// BigText approach
BT.Read(InS);
BT.Write(OutS);

But this produces the exact same result as working directly with streams and text variables:

// Text approach — same result
InS.Read(s);
OutS.Write(s);

These two pairs of statements are functionally equivalent. There is no stream-handling advantage to using BigText.

The Only Remaining Use Case

Erik concludes that there is only one legitimate purpose for BigText today: staying compatible with old code. There are still BigText variables scattered throughout the base app from the NAV era, and they still need to work. But for new code, there is no reason to use BigText.

In fact, using BigText paints you into a corner. You become limited in what you can pass in and out of functions and web services. You lose access to all the rich string manipulation capabilities available on regular Text variables.

Summary: What to Use Instead

  • Need to hold large text? Use Text — it has the same practical size limits as BigText.
  • Need to build up strings through concatenation? Use TextBuilder — it’s dramatically faster for repeated appends.
  • Need to read/write from streams? Use InStream.Read() and OutStream.Write() directly with Text variables.
  • Working with legacy NAV code that already uses BigText? That’s the only scenario where BigText still makes sense — but don’t introduce it in new code.

BigText had its day. It solved a real problem when text variables were limited to 1,000 characters. But those days are long gone, and continuing to use BigText is a habit worth breaking. Use Text for storage and TextBuilder for concatenation — your code will be simpler, faster, and more flexible.

Picture of hougaard

hougaard