I have recently received a request from a user to increase the field length of a description field in Navision. I have asked the user to research printouts, etc. to make sure that this increase in size will not visually effect their system. Can someone give me insight into how I can increase the field size?
We had made the same request to our Navision Developer, BUT they said that it was NOT advisable. It was my understanding that if the Description length is increased in the Item table, it should increased in all the tables that it ever links to, and that would be a huge project. PLUS the standard reports, and cards would not included the new length of the field, and data would chopped off. The way that we worked around it is combining Description 1 and Description 2 on all the reports so that it “looks” like one field when everything is printed, but still maintains the flexabilty of upgrading w/o problems, and having to modify a large number of tables.
You can increase length of the field but you have to search where this field is used by other objects in a database. You can do this with Navision Developers Toolkit. I’ve done this before with Customer Name and Address … it takes long time …
There are not only the Table fileds, which length have to changed. You have to change all local and global Variables in all objexts (Forms, Reports, Codeunits,…) which are used for the item description. Its a very very huge Projekt. The idea sandy explained seams to be a good solution. The only things you have to change are some reports. Greetings, Frank
Our NSC strongly advised us to keep name, description, address etc. fields at their original length and instead add a second field (e.g. “Name 2”) where necessary. Changing field length forces modifications in all objects where this field is ever used - otherwise you will keep getting “Overflow when converting from text to text” errors whenever the field is assigned to another field or a variable.
You all have wise NSC’s Nice weekend to You all! /Lars
I’ve done it so many times that i don’t feel as having something so difficult… 1) You’ve to have a clear knowledge about what tables are usually related with that one and what processes. 2) You’ve to keep in mind (and also in the user’s mind) that the description will be only increased in that table BUT it will be cut in other tables to a certain limit) (let’s say increase customer description) (you can use impulse workbench if you’re not sure). Remember that the search description, as example is usually with the code “Search description” := description… so you’ll have to use step 3 on that. 3) You’ll have to go through some tables more and use Description := COPYSTR(reftable.description,1,MAXSTRLEN(Description)) (that way you don’t have to change almost all the application). 4) Test ALL the processes after doing the change. 5) A few reports/codeunits should have to be reviewed as some of them are using fixed size variables you’ll need to increase a bit.
Hi all, I have to agree with Alfonso, it’s a bit of work but neither difficult nor time consuming, it’s just a matter of finding out where these fields are used check related reports. E.g. for customer name and adress it’s quite easy, because these fields are always “formated” via C365 and you simply have to increase the field length of the array vble. Testing is the most important part… Saludos Nils
quote:
Originally posted by sandy
We had made the same request to our Navision Developer, BUT they said that it was NOT advisable. It was my understanding that if the Description length is increased in the Item table, it should increased in all the tables that it ever links to, and that would be a huge project. PLUS the standard reports, and cards would not included the new length of the field, and data would chopped off.
Well… tell your Navision Developer that changing the Description length in the item table doesn’t mean you need changing it in all the tables that it ever links to, but just taking care that when you pass the description to those tables you just pass them the information in the proper way… in fact… if your increase it’s not too big you will have a lot of places where you should need no changes almost… let’s remember that the item description in the standard is 30 characters… but the sales lines description and the item journal description it’s 50… so if you increase the description on the item card to 50 chars it won’t be a big project at all… in fact it’s a project that can be easily finished in one or two days. Regards,
If MBS include “Extended Datatype” as in Axapta this would not be a problem. [^]
Alfonso, 1-2 days to extend a text field could be considered quite expensive versus the cost of simply adding another description field. While it definitely could be done and integrate quite elegantly, my thoughts would be to go with the additional field due to both costs to do this and “ease of upgrade” issues in the future. My 2 cents…
Bill, I agree but sometimes the customers are not wanting to have a second field and they want to use the standard one with a bigger size… no matter what you recomend them. The thing about 1-2 days it’s the worst case… depending where the customer is wanting to see that description going to (example… they’re wanting the description to be 70 chars and they’re wanting to see it on the journals also…) Regards,
What about using an additional description field. Regards, Roelof de Jong.
Roelof… sometimes they don’t want it… no matter how many times you try to explain them that’s cheaper for them… Regards,
I understand, Alfonso. I have such a customer too and the change is on extending customer’s name to 80 characters. Boy! I got to change lots of stuff. [:(] If your customer wants it, and willing to pay for the cost, count yourself lucky 'coz there are customers who don’t pay for the modification as it’s included in the package and you end up grumbling the whole day. [:)]
To you all, Both solutions are viable but there has been no mention of upgrades?!? Remember, if you do have to increase the length of a field and all the “linked” bits of code & fields, remember that you’ll have to redo this job again if your going to in the future, upgrade the database to a newer version. My personal preference - additional field.
In Attain there is already a field “Description 2” in the item table, that you can use. We have used it and on any report/form (in fact it is just on the form item) we have added a short funtion that concatenates the two fields dynamically on displaying an item. On the sales order subforms you can just display the two description columns next to each other. Requires about one hour of development and it stays very close to the standard!
We have a client that needs both Description 1 and Description 2 increased to 50 Characters. Like people have said before it’s really not that big of a job as long as you know the database structures. Having new fields would result in about the same amount of work anyway with changes to standard report etc. Either is fine by me!!
I agree with many of what you guys are saying. I can put my foot down by saying either way should be considered and relevant discusion undertaken with customer. Sometimes telling the customer the total implication of it all (such as upgrade, time involved - and that they definitely would pay for it,e.t.c) could help them think twice, and will enforce a better decision. Some customer do act almost on impulse, and as long as the developer says it is possible. By the way it also matter who we call “the customer”. There is a tendency of having a guy who is too demanding, such that if you requested a written request, it would boil to nothing. Precisely, it can be done either way. the Developer needs to have an understanding of the scope of changes from a system point of view, and understand the requirement from the customer point of view (good analysis). It is also possible to add a new field without telling the customer how you have done it, and just letting them get what they want. Keep it simple, smart, not stupid [:D] Robert
quote:
Originally posted by rbm
It is also possible to add a new field without telling the customer how you have done it, and just letting them get what they want. Keep it simple, smart, not stupid [:D]
Well… most customers that usually request having it on just one field is because they also import/export those descriptions with other programs and use ODBC for getting data from navision (and it’s easier for them having everything on just one field than having their ODBC having to search for different values on different fields. And those customers will notice that the description is not how it was supposed to be in one field… Regards,