Field Length Problem

vikram7_dabas

I am using navision 4.00SP3.I want to change the length of Customer's address field from 30 to 100 in Customer(ID 18 Table).Then,How would I know that where-2 this field is used in whole database.If i will not change the length in other tables where this(Customer Table filed Adress) flows then It will give me the Erorr of Overflow.If there is any coding to solve this problem then Plzz let me Know.

idiot

There are many posts on this. Please do a search

garak

and don't forgett, that there exist a field called "Address 2" also "Name 2"

Regards

vikram7_dabas

Dear Concern
Even using Address2, then also I need more length.

jlandeen

I find it's never a good idea to expand any of the base Navision name or address field lengths...because as you pointed out you can encounter an overflow of text to text. The compile will not raise an error because any variable assignments are still using the same type, just of different length now.

What I would always suggest to a client is to add a new longer custom field...say Long Address, that is 100 characters. Place this value on the form where a user does their data entry and then cut the first 30 characters out of this field and put them in the Address field. This way the user only has to populate 1 field and there is at least some data in the regular address field. Then change any reports or processes where you know you need the longer address block.

This should also make your life easier during an upgrade.

djswim

jlandeen wrote:

I find it's never a good idea to expand any of the base Navision name or address field lengths...because as you pointed out you can encounter an overflow of text to text. The compile will not raise an error because any variable assignments are still using the same type, just of different length now.

What I would always suggest to a client is to add a new longer custom field...say Long Address, that is 100 characters. Place this value on the form where a user does their data entry and then cut the first 30 characters out of this field and put them in the Address field. This way the user only has to populate 1 field and there is at least some data in the regular address field. Then change any reports or processes where you know you need the longer address block.

This should also make your life easier during an upgrade.

This.

Also, if I may add my own opinion into the last line:

This will make your life easier during every upgrade you ever do

jlandeen

yeah but you see now people will be scared away from changing the length if you put it like that.

I think every developer should do it once on their own....just so they really know the full impact that one little changes can have on Navision functionality and maintainability!

djswim

jlandeen wrote:

yeah but you see now people will be scared away from changing the length if you put it like that.

I think every developer should do it once on their own....just so they really know the full impact that one little changes can have on Navision functionality and maintainability!

Also true, it's great for a developer to do it, that was my hazing when I first got started

I think it's different to recommend it to a developer to do in Cronus than it is to tell a customer it's a good idea though... I haven't seen a single situation where a field length change was absolutely necessary.

idiot

Couldn't resist posting on this type of discussions again
Well I'd seen plenty where fields lengths for descriptions/names are changed and I recommend the change.
1. This should be a value-added default enhancement for the VAR to the default database, a competitive advantage to boost over others who use only standards
2. Creating a new field is good, but it's a lazy workaround easy way out, everything time something is not working just create new fields.
3. Changes the way of searching or filtering
4. This is so common that it is becoming sinful to say no to (30 chars is so old, but then again the software...)
5. Unicode/double-byte
6. Conversion/migration from legacy, what a joke if the users' old system stores everything in one field & the new system doesn't, extra work to validate correctness after breaking up the whole string to ensure no splitting of words between the fields. (who does this? the consultant or user? please place your bets)
7. Unless the client is loaded, they will typically reconsider X 10 on upgrading to new versions, unless there's something really fantastic that they like so much that they rather spend resources & downtime to upgrade.
8. What's stopping a total re-implementation vs upgrade?
9. If new versions have length 1000000000, the new consultant would question "who was the old consultant who did the previous version? why so many fields? shakes head in disbelieve"
10. "What!? No body encounters this problem? How many clients you have?"

Then again there are also reasons for not expanding the length...