One of the very first things that most new developers try to do when they start with Navision development is to increase the lengths of certain fields. Typically Item Description or Customer Name and Address fields.
Those that have been in Navision development for a long time will do everything they can to stop new developers from doing this. But are we really helping people by telling them not to do this.
I am starting to wonder …
I have been very public and verbal in telling people not to increase the length of these fields. But I am starting to think that even though the short term is disastrous, there are long term benefits to increasing field lengths.
I think that no matter how much we try to teach people to do things properly, there are some people that just must learn on their own. So you can tell a child 50 times "Don't touch the stove, its hot" and they might never learn, but let them just once touch the hot stove and they will remember for life.
I would like to know how many of the long term Navision people on this site have increased the length of fields in Navision. I will put my hand up and say it was one of the first major mods I ever did. At the time of the first upgrade, I truly learnt what a disaster that was, and I wonder if I would have learnt this lesson if I had not done it.
At first glance the task looks easy, you just need the developer tool kit, find the places its used and change. But the issue for that one Variable in some buffer code or that table that uses the field indirectly, or most importantly at upgrade time; those issues you learn later.
Maybe its time that we in the community let the beginners burn their fingers a bit. The long term effect it to have a much higher level of skills out there, and I think its obvious to everyone that the general level of Navision skills is the lowest its ever been in the history of Navision, so getting that skill set up is maybe the most important factor right now.
I raise my hand..You can count me in... :-D
I absolutely learned from that field-increasing experience.
And as I understand you... you are right... We learn from those experiences and that increases the skill level indeed.
Great to see that you're "back" as a blogger! I just love reading your blogs, as you have a perfect way to look at things from a different angle. And this latest one I'm sure has to do with the fact that you've now become a father!
But although I think that you're right - some people will never learn it. Just like some people become drug addicts. But that doesn't mean that we should stop telling our children that drugs are bad!
Just like we should not stop telling the new developers that it's bad to change the field lengths in Navision.
Keep on blogging!
Tectura Life Science increases Serial No from 20 to 30 characters.
So increasing field length does happen.
Sorry not serial No., but Lot No. in regards to Life science addon.
There are still a couple of databases where customer has insisted and have field increases.
The field have been increased to 50 characters, so upgrade to 5 or higher should be fine.
I hope NAV introduces inheritance and have the datatypes as classes/objects so this would much easier just like AX.
Yes, it would be great to have the "extended data types" in NAV in some way :-)
Im laughing at this one because just this week I had to tell a developer to undo it..luckily the changed had not been implemented on the client's production dbase.. When we train the new developer's we should have a basic list (at least) of do's and dont's ..this one included..else be ready to be called in to undo the mess somewhere..
@Rashed: Of course it happens. But as you're a very experienced developer then you also know then consequences and most likely also all the many places that you need to change the field also.
Back in 1996 then one of my main reasons for selecting the AP (Asian-Pacific) instead of the W1 (world wide) version of Navision was because it came with 50 character field length of name and address fields. This way we didn't have to do this our self. And now it's luckily a part of the world wide version!
that is exactly what I am saying, that people need to learn for themselves so they can make the decision, and know the implications. Basically the rule should be "If you have to ask, then the answer is NO". But no one listens, so easier is to let them suffer the consequences.
You have to understand that some times you can break the rules and some can't. The key is to know the difference.
Count me in :)
LOL indeed. I am a new developer in the NAV world and frankly this is not at all the right question. The real question is why does NAV make changing field lengths (and many other things) so hard? And how can that be changed? I have worked in the "real" object <-> sql world for many years, and NAV in many repsects feels like a jump 15 years into my past (I am working with the RTC and we were one of the first to go live with it). Changing field lengths in any system always has consequences but I have not worked with a system that makes it so bad you just don't want to do it for quite some time. In the real business world, requirements are driven by the business not the software. If I need item description to be 80 characters for business needs then I need it. End of discussion. An ERP system that can not adapt will eventually not remain popular. I am hopeful that as NAV progresses it will indeed become more flexible. To aid that the "experienced" dvelopers need to change thought patterns and try to stretch the box a bit. Rather than teach the "right way", why not start asking for more flexibility.
BTW, in our implementation we have had to add a lot of additional tables and fields just to get the field sizes we really need, and sometimes that is impossible. Most of it should not have been needed. The one that really drives me crazy is the 80 character comments. Our comments coming from external sources can easily be 200-300 characters and sometime longer. Last I looked text box displays and print text boxes now know how to word wrap. Many of these field length restricitons just don't fit reality anymore.
I don't think it is at all hard for a newbie to understand the reasons not to change field lengths. We just don't understand why this framework needs to make it so hard.
@Barry, the answer is simple. To maintain compatibility with the Native database. End Of Story.
You have to remember that there are 1.3 million Navision users out there that would be a little bit upset if Microsoft just dumped them. 1.3m x 16% license revenue is a LOT of money, and not sure MS want to just throw that out the window.
Oh and I put in a request to Navision to increase the field lengths back in 1992, so this is by no means a new thing. ;)
Anyway the next version will dump the native database and we can move on.
I just want to add to my blog here. Not sure how I over looked this, but one of the core reasons not to change field lengths, is performance. People tend to forget this.
I am currently working on performance issues with a well known Navision Add-On that changes field lengths in base fields. The system performs like a dog, and the only solution is going to be to re-write core parts of this Add-On correctly.