Extending Code Field 20 -> 40

bLuB

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.

Juhl

For Big tables, could you hit sql max????

BlackTiger

Kepty wrote: »

What? Search description for the Lot number? It doesn't make sense... You need the Lot number of medicaments in all transaction and you have to track expiration dates of Lot numbers before you make any warehouse movements etc... It is impossible to create a new field because of complexity - it so easier to change field length.

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.

NavSolution

its not helping you if passing field in parameter ,cause name is not same as field.

bLuB

Extending fields and find where those fields are used in parameters is not easy but its possible. Have done this multiple times. But extending the Code20 to Code40 means. that you have Item No. with Code40 GL-Accounts with Code40 ..........
Neverending story which is just a overhead and absolutly not a nice way of development imo.

NavSolution

bLuB wrote: »

Extending fields and find where those fields are used in parameters is not easy but its possible. Have done this multiple times. But extending the Code20 to Code40 means. that you have Item No. with Code40 GL-Accounts with Code40 ..........
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.

mohana_cse06

this is where the problem starts.
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

bLuB

mohana_cse06 wrote: »

this is where the problem starts.
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

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.

AK

If you can't avoid doing it, you have to do it by using a "where used tool". Otherwise you will miss every function where the field is passed as a parameter or returned and every variable which is supposed to store values from that field. The approach of you colleague is therefor very silly and will create even more problems.

RockWithNAV

If you doing this or your custom added fields then I will suggest go ahed but doing this for standard fields is something which you shouldn't actually because you literally cant even anticipate what wrong could happen and eventually it may turn out to be a nightmare rectifying this.

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.

Juhl

For Big tables, could you hit sql max????

Yury

<joke>Great issue! Really great!</joke>
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.

Kepty

There are some reasons why we had to change the text/code length in the past
- 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)

BlackTiger

There is NO a tiny single reason to increase any field length in NAV.
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.

Kepty

What? Search description for the Lot number? It doesn't make sense... You need the Lot number of medicaments in all transaction and you have to track expiration dates of Lot numbers before you make any warehouse movements etc... It is impossible to create a new field because of complexity - it so easier to change field length.

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...

BlackTiger

Kepty wrote: »

What? Search description for the Lot number? It doesn't make sense... You need the Lot number of medicaments in all transaction and you have to track expiration dates of Lot numbers before you make any warehouse movements etc... It is impossible to create a new field because of complexity - it so easier to change field length.

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.

bLuB

Kepty wrote: »

What? Search description for the Lot number? It doesn't make sense... You need the Lot number of medicaments in all transaction and you have to track expiration dates of Lot numbers before you make any warehouse movements etc... It is impossible to create a new field because of complexity - it so easier to change field length.

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...

Mostly we have to extend Serial and Lot No. we need to full functionality of this but with bigger size.