text size

Horse06

Hi, I have a problem here which is very simple, but I don't know why the system has error this time. We expand the customer Name field from text50 to text100 and also change the description to text100 as well from Gen. Journal Liine table. But when we select customer ID from Account No, the descption will not accept the customer name from Cash Receipt Journals, Error is text flow. I have fixed this problem many times, but it doesn't work this time. After we deleted some characters from customer name of customer card, the value is accepted in the description field of the Cash Receipt Journals. My confusion is Custome Name text length matches exactly the length of description. Why the long name is accepted in Customer Card, but not accepted in Cash Receipt Journals? Your advice will be greatly appreciated!

Savatage

turn on the debugger see where the problem is. It's not an unexpected error message - there are probably 1000 posts and 1000 reasons on problems you can run into when you expand fields and don't find everywhere they are used.

Horse06 wrote:

I don't know why the system has error this time............
I have fixed this problem many times, but it doesn't work this time..........

as I see you found out.

Also, any future updates/upgrades you will have to keep making these changes. Remember they can also be a part of another variable (which means the variable now has to be expanded everywhere), especially the description field which can take a value from many different places.

garak

it could also be, that you've forgotten to change also same variables / parameters in functions.

so start the debuger. He will stop at the function where the error comes ...

EDIT
Sava, i need the same fast keybord like yours, because yours is faster .... :whistle:

DenSter

If you extended the Customer Name and the General Journal Description, both to the same lengths, then the error must be on some other field, or in some variable. Using the debugger is your best bet.

kine

Horse06 wrote:

Hi, I have a problem here which is very simple, but I don't know why the system has error this time. We expand the customer Name field from text50 to text100 and also change the description to text100 as well from Gen. Journal Liine table. But when we select customer ID from Account No, the descption will not accept the customer name from Cash Receipt Journals, Error is text flow. I have fixed this problem many times, but it doesn't work this time. After we deleted some characters from customer name of customer card, the value is accepted in the description field of the Cash Receipt Journals. My confusion is Custome Name text length matches exactly the length of description. Why the long name is accepted in Customer Card, but not accepted in Cash Receipt Journals? Your advice will be greatly appreciated!

Now you can see, why each time somebody ask if it is possible to extend the fields, answers are, yes, but be aware possible problems. Rather than extending the fields, try to use Name 2, or Description 2 etc. and correct the reports to print both fields in correct manner.

Eugene

whenever i need to extend a field i run DevToolKit to find out all the places affected by the change

DenSter

and that still doesn't give you all the places where it is affected.

Eugene

and that still doesn't give you all the places where it is affected.

lol, how can you state that? you don't even know what exactly i do with DTK to find the places. It is like stating that "10+10 <> 100" without knowing what base is being used

DenSter

you're funny Eugene. Thanks for the entertainment

Eugene

do you know of certain things DTK cannot find - some kind of bugs in it ?

awarn

Eugene, perhaps you will educate us how you deal with what garak mentioned, finding the variables / functions that deal with the description field of all of the tables affected?

If the answer is:
I find all the fields that might have customer name copied to it, and then for each of those (probably like 500 places), I find every variable / parameter in the database that relates to each of those, then I find every variable / parameter that relates to each of those variables / parameters, (and then repeat as nauseum) and extend all of those to the new length, and then repeat this process every time the customer upgrades.

Then that is a great example of why you should just try to find the 2-3 reports and forms that the customer is concerned with and add the field to those places. In fact, that very explanation to a customer (where they can see the $$$ signs flashing through their heads) usually changes their opinion on how to handle long names.

-a

idiot

Oh I like this kind of posts!
It's always costs vs effort vs accuracy.
If my customer name is "THISISMYCUSTOMERNAME GLOBALIZATION WORLDWIDE DISTRIBUTION", which is not uncommon, especially wit doublebytes, you need 3 fields...

Then it comes to how you search/filter for customers when you have same 2 customers with same first names...

Then it comes to how you formulate your SQL queries, assuming you do....

Stardust77

Awarn, you might be right for the names, addresses, and description in English, which are much shorter than in other languages, but what can you do when the Name does not fit in other languages?

I have to confess that I have expanded all the Name and Description fields, and I know very well how difficult it is to do it, but with the help of the Debugger I have succeded. Not sure that it was changed everywhere, maybe when using a new granule the error will pop up somwhere else, but it is easy to fix.

awarn

Hi,

You can do it, but the question is, is it worth the time and effort? Or could it be done by using the Name 2 /Description 2 fields?

I have worked for years in a database with a large vertical (Wisefish) that has been installed and translated for Icelandic, Norwegian, German, Italian and Spanish along with English. I have not come across the absolute necessity to increase the field length in the Name field.

Here is the thing. If you develop a vertical solution that works 90% of the time, and the other 10% of the time you need a minor workaround, then you have succeeded. If you try to hit 100% for everybody (for a vertical), then you are putting your effort in the wrong places.
If you are working with a customer who has a budget of 500 hours, you want to give the customer as much good functionality as possible for those 500 hours. If you spend (just throwing out a number) 40 hours increasing the length of a field, when you could have spent it on 2 really good reports (along with adding the Name 2 field in a few places), then they are getting less for their money.

If the requirement is an absolute necessity - then do it. But remember that balancing effort and results in projects is what makes your company money and your customer happy.

-awarn

awarn

Here is an example of a situatino we had a few years ago.

Client wanted to keep long customer names, because they dealt with state liquor regulators, and needed some reports to have the full legal name of a customer.

We added a new field to the customer card, called 'Legal Name', 250 characters.

We changed the customer invoice and the three shipping reports to show the Legal Name field instead of the Name field.

however we did not change any journals, ledgers, or other functions, because to our client, seeing the text 'Franks Store' on a form was OK. They did not need to see 'Franks Store of Fine Liquors, wines beers and other goods Imported & Exported Trade Limited'. The only place that big long name was needed was on outbound documents.

The side note is that if we had needed it in the customer ledger, we could have made a flowfield...

-awarn

Stardust77

=D> You know, that was a great idea. So simple and so effective! Thank you, I will do the same.

idiot

awarn wrote:

Here is an example of a situatino we had a few years ago.

Client wanted to keep long customer names, because they dealt with state liquor regulators, and needed some reports to have the full legal name of a customer.

We added a new field to the customer card, called 'Legal Name', 250 characters.

We changed the customer invoice and the three shipping reports to show the Legal Name field instead of the Name field.

however we did not change any journals, ledgers, or other functions, because to our client, seeing the text 'Franks Store' on a form was OK. They did not need to see 'Franks Store of Fine Liquors, wines beers and other goods Imported & Exported Trade Limited'. The only place that big long name was needed was on outbound documents.

The side note is that if we had needed it in the customer ledger, we could have made a flowfield...

Excellent idea.
But doesn't this defeat the purpose of having customer code in the 1st place?
Now's there a customer short name to represent the customer, which duplicates the customer code's intention of representing the customer....

-awarn

awarn

No, it does not defeat the purpose of a customer code. Remember that the purpose of this thread is how to deal with extra long text fields.

Example:

Customer code: C001
Customer Name: IBM
Legal Name: International Business Machines

Customer code: C002
Customer Name: CBS
Legal Name: Columbia Broadcast System

When you register a business, you normally need a unique name, but sometimes you use an acronym or shorter name for everyday purposes.

Think about it at the level of someone using Navision. Internally they call the company CBS, but when you ship something to CBS maybe CBS requires that the shipping documents contain the text 'Columbia Broadcast Systems'. Not everybody knows that CBS the television station is really Columbia Broadcast Systems.

idiot

Maybe I'm slow but I'd like to learn something from this thread, to revise my database concepts...
If I were to use Customer Code = IBM or CBS wouldn't it achieve the same effect?
If it happens that there are 2 company's whose initials are both IBM, IBM1 & IBM2 does the same things doesn't it?

DenSter

It doesn't matter what you use for the customer code, that is only used to uniquely identify the record in the database. In fact if you would look at it Philosophically, you would prefer that the code has no meaning at all, so IBM and IBM2 would not be good candidates, becuase that does have meaning.

The issue at hand is that the default length of the Customer Name field was not sufficient to store the name, and this thread is about various solutions.

idiot

Well isn't each customer supposed to be unique?

This thread is about various solutions. But without understanding the problem there can be no solution. I'm trying to learn how to apply the suggested solutions to real-world problems...

Nevertheless this shall be my last post in this thread.

awarn

Idiot,

I think you are totally missing the point.

Example: Your client wants to have the customers in their datbase use a number series starting with C01155678, because in their legacy system this was the next available number, and they like to keep the numbers sequential.

Your client deals with the government and they need to reprot the full legal name of the customers on some documentation. This could be up to 200 characters long.

Here is a scenario where you need a Code 20 customer code (already there), and a field of Text 200 (not there yet), which is needed on 3 custom reports.

Solution #1 - estimate - 4 hours. Add a new field to the customer card, Legal Name. Add this to the 3 noted reports.

Solution #2 - estimate - 40 hours. Change the descriptin field from text 50 to text 200, and everywhere in the database where this could be used.

Do you not see how solution #1 might be a little easier?

Stardust77

awarn wrote:

Solution #1 - estimate - 4 hours. Add a new field to the customer card, Legal Name. Add this to the 3 noted reports.

Solution #2 - estimate - 40 hours. Change the descriptin field from text 50 to text 200, and everywhere in the database where this could be used.

Do you not see how solution #1 might be a little easier?

You are right. However, if I could charge 4 hours for the Solution # 1 to my customers, I would be very rich already. \:D/ I would say that is more realistic 1 hour, including smoking and coffe break.

awarn

LOL can't argue with that.

DenSter

Well pure development time yes, we can all make that change in a few minutes. Include communicating the objects to the customer, assisting the test work, moving the object to the production database, notifying the customer, things like that add up quickly. 4 hours is not a bad estimate for a change like that.

djswim

The only way you should ever let a customer do this is if you have a new consultant or developer on staff that you want to haze. This is perfect for that. This not only teaches them how intertwined everything is, but also will make them hate it enough to never want to let a customer do this ever again, unless there's a new consultant or devel.... and the circle of life continues

Also, as far as using the DTK to find everywhere else the variable is passed, you can do a really good job, but honestly after a while it's not worth trying to track it down anymore and just be available for the occasional debug/fix for the 5-6 more overflow errors you're going to get.

awarn

djswim, that is the best tag line ever:

"OMG ALL MY DATA IS GONE"
"Show All..."
"Oh..."

djswim

I tell all my customers that it's my favorite support call ever, because it still gets me about once a year

DenSter

djswim wrote:

Also, as far as using the DTK to find everywhere else the variable is passed, you can do a really good job, but honestly after a while it's not worth trying to track it down anymore and just be available for the occasional debug/fix for the 5-6 more overflow errors you're going to get.

You know that's not a bad approach either, kind of pragmatic, but relies on the customer not freaking out or get very angry when they get an error like that. Make the customer aware of the fact that catching all of them is just not worth the time, and to simply call when they run into an overflow error. That kind of gives you a mask for 'development features' too

djswim

Yeah, I'm always very up front about what is going to happen as a result of the change and what's involved. This helps when the calls come later on... a really good idea for a proactive, involved client. Not so much recommended for the scardy cats that filp a lid every time they get a "Posting Date out of range" error

Stardust77

djswim wrote:

The only way you should ever let a customer do this is if you have a new consultant or developer on staff that you want to haze. This is perfect for that. This not only teaches them how intertwined everything is, but also will make them hate it enough to never want to let a customer do this ever again, unless there's a new consultant or devel.... and the circle of life continues .

I believe that it is what a new developer would like most: to perform some very complicated tasks, and to start immediately write some code.

In fact, thinking very well at this issue, I understood why the simplest way to solve this issue did not come into my mind. The very first time when we were asked by a customer to do this, our senior developer at that time did it this way. I took it as it was, and never considered it can be done easier. :oops: