Documentation or Implementation Bug? Unlimited Code Length

3/4 of a year NAV 2015 is on the market and nobody so far (at least that I could trace on the Internet) seemed to have noticed. I guess we all have sleeping. Seems including MS as it hasn't been fixed.

Did you read this?

Click on the image to go to the msdn help topic.

Great, so eventually code variables are treated the same as text variables with respect to their length.

Well ... bummer ... no. Try it yourself.

Clearly a bug, but the question is: documentation or implementation bug?

I go for the latter. 

  • Thanx, Stuart. Glad I didn't make a bet with Erik. ;-)

  • Erik is right, was a doc bug.  Should be updated on MSDN by end of June.

  • Thanx, Erik. This as such doesn't tell me it's not an implementation error. However the additional argument you gave on FB makes more sense:

    What should the purpose be? In what case do you need an "auto-trimming-uppercasing" string thats longer than 250 (max. in database) ? I can only come up with cases that are bad programming for that.

    Still makes me wonder about the why behind the documentation change as the 2013 R2 topics still seems to apply. What triggered that change?

  • Its an documentation bug, here is a decompiledd part of the NavCode .NET class

     public class NavCode : NavCodeBase


       private static readonly NavCode[] cachedNavCodes = new NavCode[250];

       private static readonly Func<int, NavCode> createDefault = (Func<int, NavCode>) (maxLength => new NavCode(maxLength, string.Empty));

       public const int MaxSize = 1024;

       private string value;

       private bool needsUpperCasing;

       private readonly short maxDefinedLength;

       private readonly byte alphaIndex;