Change the length of code type in the key

Anonymous

Hello,

I should like to know your opinion on the next topic, if someone has already met this request :

My customer asks me to change the length of the "Series No." (CODE20 to CODE30), this seems very risky (not to mention the work to do and tests to do), what do you think? Do I have to dissuade him from doing this?

Thanks you for your reply.
Regards

Benoît

David_Singleton

Do not do this.

kriki

David Singleton wrote:

Do not do this.

I would even say:
DO NOT DO THIS!

Upgrading to later versions will become difficult.
The fields are used everywhere and it is possible that after months after it gets in production an error comes up to haunt you.

matttrax

If you get the point that you have to quote it (hopefully not), the amount for the work to perform should probably persuade them not to do it

Like the others say, DO NOT DO IT.

kine

Question is - why the customer need it?

DenSter

kriki wrote:

David Singleton wrote:

Do not do this.

I would even say:
DO NOT DO THIS!

I would even say:
DO NOT DO THIS!!!!!!! [-X [-o<

generic

Well if you must do it, and I think you have received plenty of warning, is to export all the objects to Text,
and Do a Findand Replace all CODE20 to Code30.

This will change everything in the system to Code30, but at least you won't run into any overflow issues.
It shouldn't take more than an hour to do.
This would be the safest way to do it.

kine

generic wrote:

Well if you must do it, and I think you have received plenty of warning, is to export all the objects to Text,
and Do a Findand Replace all CODE20 to Code30.

This will change everything in the system to Code30, but at least you won't run into any overflow issues.
It shouldn't take more than an hour to do.
This would be the safest way to do it.

But even in this case you will have big chance of some problem, and in this case it will be in most cases in totally different area than No. Series... :whistle:
(e.g. when Field3 := Field1 + Field2; now will lead to error, because before it was Text50 := Code20 + Code20 and now it would be Text50 := Code30 + Code30;)

generic

kine wrote:

generic wrote:

Well if you must do it, and I think you have received plenty of warning, is to export all the objects to Text,
and Do a Findand Replace all CODE20 to Code30.

This will change everything in the system to Code30, but at least you won't run into any overflow issues.
It shouldn't take more than an hour to do.
This would be the safest way to do it.

But even in this case you will have big chance of some problem, and in this case it will be in most cases in totally different area than No. Series... :whistle:
(e.g. when Field3 := Field1 + Field2; now will lead to error, because before it was Text50 := Code20 + Code20 and now it would be Text50 := Code30 + Code30;)

Show me a code in Standard Nav that does this for Code type fields.

DenSter

generic wrote:

It shouldn't take more than an hour to do.

Famous last words

kine

generic wrote:

Show me a code in Standard Nav that does this for Code type fields.

Ok, example: When copying shipment lines into invoice to invoice them, there is inserted line in format:

Shipment No. XXXXXXX:

In ENU it is not problem, you have still enough space, because description in Sales Line is 50,text constant have 14 characters, document no. will have 30 characters, you have max. 44 characters. But if in some language the text will have length more than 20 characters, you will have error. And I am sure, that you will find more examples of this...

generic

That's still not an good answer, and it's a minor example. And It's not a problem based in ENU as you mentioned.
Anybody else has better examples?
The programming changes would still take same amount of time. With testing they could quickly check all their processes.

idiot

Besides,

kriki wrote:

Upgrading to later versions will become difficult.

, what other reasons are there for

David Singleton wrote:

Do not do this.

?
I'm trying to compile a list of justifications for not increasing the field lengths.
Please help by contributing more rationale.
So far I have
1. the quoted
2. difficulty in maintenance if not done properly (increasing the displayed field in reports, forms, etc if truncated)
3. use of Description 2 (not applicable in this case)
4. consultant charges of increasing the field length
Thanks.

kine

5. Find and solve all problems because this change is not 100% possible and you could have errors about length overflow more than few months after the change and someone needs to solve them.

DenSter

6. increasing the length of a code20 primary key field is not necessary. It's just a primary key value, and assuming that you'd only use numbers and letters, you'd have 37 ^ 20 different possible values (26 letters, 10 numbers, non-value/blank). I doubt that they'd need more than that.

garak

@BDurand: there are a lot of post here in this forum about these theme.
Even the first question is ever:
Why your customer need this?
And it's not only the No.-Series that u must change. All field (like Customer No., Item No., and so on) that have a relation to this table must be changed in the lenght. And all other field that has a relation (by tablerelation or through some code in the Onvalidate/Lockup or some self definde/standard functions) to this fields (Customer No and so on) must also be changed .........

So, explain your customer, based on the tips here, what this have for an impact .....

Regards