NAV 2013

Unlimited Text Length in NAV 2013

imageHave you noticed already that in Microsoft Dynamics NAV 2013 the text variables can have unlimited length? That’s quite a leap ahead of the previous versions which couldn’t handle more than 1024 characters per variable. If you wanted to achieve bug-free code then, when you were assigning texts around, you had to concatenate the result down to the MAXSTRLEN of the target text.

Not anymore.

The trick is to simply not declare the Length property on text variables. If you declare a variable of type Text, and then leave the Length empty, it means – unlimited.

Don’t worry – you won’t kill NAV by eating up all the available memory. Underneath C/AL there is .NET now, and strings in .NET are of unlimited length, or better yet – unlimittable – length anyway. Strings will only make things slow if you stuff the revised version of King James’s Bible in them. In all practical situations, there will be absolutely no performance penalty of leaving Texts unlimited.

I don’t know about you, but from tomorrow morning, I won’t be setting Length to my Texts.

11 thoughts on “Unlimited Text Length in NAV 2013”

    1. Kamil – thanks for pointing out. There is a trick here with .NET, making this only an optimistic theoretical limit. If you depend on that value with the previous algorithm of NewString := COPYSTR(OldStr,1,MAXSTRLEN(NewString)) and actually try to assign 2 GB of data to that string, you’ll get an overflow! The problem is that though the limitation of the string is at 2 GB, every character in a .NET string is 2 characters (due to Unicode), thus you can only assign half that limit before you get an overflow error. That would be a .NET error I assume, not the standard C/AL Text[2] := Text[4] kind of overflow error.

      Btw – I was overly enthusiastic last night and didn’t think much of the practical aspects of the fact that it is now unlimited, but if you want to be on the safe side, you still need to do COPYSTR/MAXSTRLEN thing, because you may try to assign Text to Text[size], and it may end up being longer. Yon can omit using this only if all the texts are unlimited.

  1. Yes, the possibility is good thing, but as each time, developer must be sure what he is doing. It will take some time to “raise the limits”
    here, mainly when the fields in tables are still limited. Thus there will be some point where you need to use the MAXSTRLEN and this problem of “100 doesn’t mean 100” could be very annoying.

  2. By “Don’t worry – you won’t kill NAV by eating up all the available memory.” do you mean that .NET prevent mere mortal like me to end up with a Stack OverFlow error message ? 😉

Leave a Reply