Unlimited Text Length in NAV 2013

  • Post category:NAV 2013
  • Post comments:11 Comments
  • Reading time:2 mins read

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.

Vjeko

Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

This Post Has 11 Comments

  1. Kamil Sacek

    In this case, MAXSTRLEN will return 2147483647, thus the limit is there… but… 🙂

    1. Vjekoslav Babic

      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.

  2. Kamil Sacek

    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.

  3. Tarek Demiati

    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 ? 😉

  4. Tarek Demiati

    When you’ve been using defensive programming techniques :
    http://en.wikipedia.org/wiki/Defensive_programming

    It’s hard to say, let’s stop doing this grunt work since it’s going to be handled by some sort of garbage collection feature which is part of the framework 😉

    But i guess that’s one of the beauty of managed vs unmanaged code 🙂

Leave a Reply