Hello,
we have an internal discussion where I need your advice.
As long as I develop NAV changing fieldlength is always a thing where you have to think about alternatives for this.
I would change the field and search all related fields and functions and so on ..
BUT a collegue wants to do this by exporting all objects as text and replace ALL Code[20] fields to Code[40]. ALL Code fields.
What I need from the best community is pros and cons for this approach. I'm absolutely against this.
So correct my standing or tell me why this is a bad idea. I need some good arguments.
-1
Answers
Neverending story which is just a overhead and absolutly not a nice way of development imo.
You are right but if there is Requirement for this thing then you must to do that right.
we as experienced NAV people need to explain customer what problems will occur with such requirements.
this is what I refer whenever such requirements arise
https://dynamicsuser.net/nav/b/singleton/posts/increasing-field-lengths-in-navision
-Mohana
http://mohana-dynamicsnav.blogspot.in/
https://www.facebook.com/MohanaDynamicsNav
yes that the thing you have to be really aware. But also if there are problems with extending fields (and those are problems we can fix) I believe it's so much better to go the approach of checking the relations and params and so on before replacing everything from Code20 to Code40.
The question here is not if it's smart or easy to extend fields. The question was how to do it.
Still if it's that utmost urgent then you can do this in test DB and put it in under consideration for 1 month where all transactions and business process should happen. You will get the picture.
Blog - rockwithnav.wordpress.com/
Twitter - https://twitter.com/RockwithNav
Facebook - https://facebook.com/rockwithnav/
I understand issues like "change all "Description" fields lenghts to 150..", but this one is really funny. Sorry...
But now seriosly. Ask youself "Why do we need it?" Write "+/-" arguments and think a little. Could your specific problem be solved another way?
In my 15+ years NAV experience opinion, such issues are waste of time. And in 80% of cases - consultant/architect/developer/analyst incompetence.
Yury
- Customer name is too short and due to Czech law, we need to print complete register name of the company (and the fields are too short)
- Some of the item identifiers (like lot number) are too short for some specific goods like medicaments or pills (and it is necessary to track this due to laws)
Item "No." is not enough? Use search description, item cross reference no., "No. 2" etc.
Customer name is not enough? Use "Name 2", create a new additional field.
Etc.
Other words - use your brain and developer imagination.
By the time you get it built, they’ll want something new.” Steve Jobs
And customer name? We have some customers with the legal name with 120 characters. And what to do with this? Split the name to Name and Name 2 is not enough. Creating a new field for this is too complex because you have to propagate this new field to all vat reports, documents, etc...
As I said - use your NAV knowledge and imagination. There is a lot functionality in NAV, you don't have to use item number for it. (in your "example" when existing lot number is not long enough the proper solution is to create another "Lot No. 2" field in "Lot Information" table and use internal lot numbering for existing field).
Of course you have to modify reports to support "full name"! This is a basic NAV developer's job. Very basic. It takes 5-10 minutes per report. But you don't have to modify DB/app structure, which is MUCH MORE complicated and risky job.
Very pointless discussion.
By the time you get it built, they’ll want something new.” Steve Jobs