Extend Cross reference field lenght

StefanNuijs

Member
We like to expand the Cross reference description field length from approx. 44 characters to approx. 70 characters. The first technical reaction was that is was not possible.
I have worked a lot with other ERP programs and cannot imagine it is not possible in JDE.

Can someone convince me of the possibilities?
 

RussellCodlin

Reputable Poster
Custom column, custom tag table and enhancements/modifications where you would like to use the field.

Changing the size of standard fields in JDE is pretty much like juggling land mines whilst walking through a field of land mines. In theory it is possible but the dangers just don't make it worth it. There hasn't been a JDE customer yet that hasn't asked for a description field to be increased from 30 characters. The reason they are still 30 characters after 30 years is that the change is a technical nightmare that even Denver doesn't want to touch.
 

BOster

Legendary Poster
As Larry Jones so eloquently put it many years ago on JDEList.

"Changing a custom DD item size is like pointing a gun at your foot and pulling the trigger. Changing a pristine DD item size is like pointing a gun at your head and pulling the trigger."
 

Larry_Jones

Legendary Poster
Can you imagine it now? :rolleyes:

I don't disagree - you'd think a big "modern" ERP system would have this capability. However,
the issue is that the big survivors of the early MRP/ERP Wars didn't prioritize this kind of flexibility in their architectures.
From what I googled SAP has similar issues and apparentl;y it isn't easy in E-Business Suite either.

Smaller, more nimble packages may have this capability - but the bigger and older dinosaurs have too much legacy code (and customer's custom code) to be able to add this ability.

Net, net if you change the field size of a standard Data Dictionary field that may be used in multiple places ... just make sure your resume / CV is up-to-date.
 
Discover how to build no-code data integrations and business process automations.

BOster

Legendary Poster
The biggest problem is all the C code and strings where the string size is hard coded in the character array in any non-generated code.

Code:
JCHAR  szBusinessUnit[13]={0}, szSomeOtherVarThatHasNoIndicationItIsMcu[13]={0};
...
jdeStrcpy(szBusinessUnit, lpDS->szBusinessUnit);
...
jdeStrcpy(szSomeOtherVarThatHasNoIndicationItIsMcu, szBusinessUnit);

If they would have just made a few minor tweaks to the tooling and if they (and by extension us) would have implemented a few better C coding practices it would not be the big mess that it is today. In other words, even with C code they could have made it possible to change DD item sizes and all that would be needed would be a recompile and probably something to alter the DB table. Hind sight is 20/20.
 

jdelisths

Reputable Poster
I think the problem is failure to adopt/implement a better programming language in E1. Case in point: PeopleCode, I hear is a "real" OOP language. RDA / FDA / NER are poor substitutes (no offense to any one) for real programming languages. The idea behind implementing point/click code was to allow business analysts and functional expert users to make changes without having to go through IT or a developer.

Smaller, more nimble packages may have this capability

Smaller packages may be small, but they do have good functionality. Microsoft CRM allows you to change (or even add!) almost any field in the underlying table without programming changes. You can also change forms (only now introduced in E1).
 
Top