For long, we (as a partner community) have been asking for longer field lengths. And this time, Microsoft seems to have delivered: about 860 field lengths were changed. Mostly from Text50 to Text100, but also from Text30 to Text50 and so on. For your convenience, I created a csv on my “CALAnalysis”-repo on github that lists all of them.

Caveats

With this change, there are some caveats that I can think of – and there might be even more then I list here below.

First of all: what if a Business Central database contains C/AL customizations or AL extensions or apps on AppSource? If a database is being upgraded to the Spring Release, and in your code, you assign the field that is now Text100 to some other field in your solution that is probably still just Text50 – there is a danger for an overflow, which (I think) is a runtime error.

In case of extensions, in theory, code analysis should catch this. You should get “overflow” warnings when you compile your code against symbols from BC version 14. For an app on AppSource, ISVs should already have caught it this way in their build against the “next version” (insider) – if they had set that up of course.

For “Per Tenant Extensions”, you typically don’t set that up, so I’d strongly advise to start checking all these extensions, as unexpected errors might happen once people start using these lengths.. . I only can imagine what kind of situations that would cause – it could turn into a support-nightmare.. .

For customizations (I mean ANY solutions that are still in C/AL), you are quite “bleeped” (sorry for my French). Because we don’t have code analysis there -no way any compiler is going to help us. So if you upgrade your C/AL to the spring release, I’d highly advise you that you really take this into account. I will suggest a few ways to handle this going further in this blogpost.. .

Another caveat I can think of is reports. All of a sudden an item description can be 100 characters. I don’t know any report that fits 100 chars as a description – or I am missing something. And do realize, we are talking about 860 fields here, not “just” the Item Description. So potentially any kind of text-field on a report can run into not being fully displayed.. . Don’t know about you, but I know my customers will not appreciate this.

What can you do?

Code Analysis

The most obvious thing to do is compile your code against the latest release. With this, for any kind of extension, and especially the ones that are on Business Central SaaS (since this will get upgraded automatically), you should set up a scheduled build against the “next release”. You can easily do that with DevOps in combination with Docker. And in these cases, it’s highly valuable, as you would catch many of these possible overflows like that.

Though, I don’t know about TRANSFERFIELDS and may be other statements that assigns values to variables. Please pay enough attention to this.

The way to solve this is to also change the field lengths of your fields. Not by cropping any values and losing data in the tables where it would end up obviously.

Roll Back Microsoft’s changes

This probably sounds like the most ridiculous option your can do. I mean: change 860 field lengths back to their original lengths? Are you kidding me? Well, first of all, in my opinion, it’s a valid option for OnPrem C/AL solutions (obviously not for any kind of extension/app solution). It’s actually what we did – at least as a temporary way to go. The reason is twofold: first of all, this is our last C/AL release of our product. Next release will be full-extension. If we would do any migration to our new solution, then there is no problem. Second reason: this was the only way we could 100% identify all the changes we needed to do to make the whole solution stable again (frankly, we weren’t waiting for bigger lengths). Because after quite some attempts, there was no way for us to identify where we assign these changed fields, and where it would eventually end up in any kind of custom fields that might cause a problem.

May be a third reason of the two I was going to mention is: We could automate this.

This is the simple script that we used to roll back these changes (my colleague created this one, which was twice as fast as my version ;-)): https://github.com/waldo1001/Waldo.Model.Tools/blob/master/ChangeObjects/RestoreFieldLengths.ps1

Change all Text-datatypes to Text100

If we can do the above, we would also be able to identify all Text-fields with a length lower than 100 – and we would be able to change them to 100, right? It’s actually fairly easy to do, but in my opinion, not 100% safe (as some Text-fields were changed to 260 or even 2048).  And obviously, it wouldn’t solve the report-problem … .

So we didn’t go for this option, and I can’t get you the script, but at least you have the building blocks to do it ;-).

How did I analyze this?

Well, as you might have read, I used this code analysis tool that we created internally (and blogged about in this post). The script to compare the fieldlengths and list the differences in datatype, you can find on my github here: https://github.com/waldo1001/Waldo.Model.Tools/blob/master/Analyze/CompareFieldLengths.ps1 .

So – we survived the snap – hope you will as well ;-).