Have 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.
Pingback: Unlimited Text Length in NAV 2013 - Navigate Into Success - NAV Non-Technical Blogs - Microsoft Dynamics Community
Pingback: Unlimited Text Length in NAV 2013 – 6/13, Navigate Into Success | Partner Compete
In this case, MAXSTRLEN will return 2147483647, thus the limit is there… but… 🙂
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.
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.
Pingback: Page not found « Danjo's two cents
Pingback: Unlimited Text Length in NAV 2013 | Pardaan.com
Pingback: (my struggle in) “believing” Microsoft Dynamics NAV 2013 (NAV 7) « spot in the globe
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 ? 😉
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 🙂
Pingback: NAV2013: HTML on reports - Waldo's Blog Microsoft Dynamics NAV - Microsoft Dynamics NAV - Microsoft Dynamics Community