Having a little brain stumble this morning. I am needing to increase the OrderHed.UserChar1 x(30) to x(100).
I’m not sure but…
I’ve always been told not to try increasing format size of a “standard” field.
i.e. any fields that show up in the data dictionary viewer?
1 Like
Sometimes some fields are only limited to a certain length on the UI but not SQL. In this case UserChar1 is limited to 30 in SQL so using something like Extended Properties Maintenance wouldn’t work.
In this case you are a bit out of luck and need to create your own UD Field instead.
You’re better off adding a UD field of the size you want. UD Column Maintenance will let you add your own fields to the table. You’ll have to do a regen afterwards, but you’d have to do that anyways if you tried to modify an existing field.
3 Likes
That is what I was thinking, but didn’t know if I was missing something. It is a Monday after all! 
Those “UserCharXX” Fields were built way back in the day when there were not any UD FIelds available. They were some special use cases, and even ORIGINALLY supported adding Labels to the definitions, and then they were exposed in the UI… but those days are way back (Version 6?)… Later we added a set of UD Fields (ShortChar01-20, Charactor01-10, Number, Date, etc) which could be used for UD FIelds… then later, we MOVED those fields (If in use) to a separate UD Table to hold those fields… WHY? Because it was more efficient AND we allow you to ADD your own UD Fields with your own field names. With the ability to add UD Fields into the tables, the need for these legacy fields are very low… in fact, I would guess that very few people (except long time users) actually use them and they are probably blank in most users systems.
My Recommendation:
- DONT use any of the pre-canned UD Fields
- Instead, Create your own UD FIelds with meaningful field names (Nothing worst than wondering “What is Checkbox03 used for?”)…
- Use your new fields without risk of them ever being overwritten by some other customization or future upgrade because YOU named them… (In fact… if I were to create a new field such as “OrderDtl.PromiseDate_c”, I would actually put a company SUFFIX on it… such as “OrderDtl.PromiseDateACME_c” just to make sure that if someone else comes along with a PromiseDate field, it will be Special.
2 Likes
Only available for on premise or self managed cloud users right?
I did in Public Cloud/Dedicated Tenant.
1 Like
one day… (probably not ever, actually… 
)
I thought it possible in MT too. That field is “shared” with others in the same tenant and requires some planning. Maybe they don’t do it any longer…
Reason 249 to kill MT…
I stumbled upon this post after being asked to adjust the character size of a field we are using (OrderHed.UserChar1-4).
Creating new UD fields are nice and easy but is there a way to not lose the data in the old field and automatically populate them into the new UD fields I would create?
“Automatic”? no… but you could create the new fields, then create a BAQ to export the old values, and then change the field name in the exported table to the new field name and use DMT to import the results.
That sounds about right…
Do you know of any way to check and see what dashboards the field itself is used in? I am pretty sure somewhere out there is a dashboard my predecessor created with these fields referenced.
i know someone out there has probably created such a tool with a BAQ that searches all the BAQs in the system to find one that has the field you are interested in. (Remember, a BAQ is just another table in the system, so you can write a BAQ that looks at BAQs 
)
Why do we need a suffix? Is that suggestion for cloud customers?
it is actually a requirement that all UD FIelds have the _c at the end. this keeps your UD Fields separate from anything that Epicor might release at a later date… for example, if you created a new field called OrderDtl.PromiseDate, then when 2024.1 comes out in a few months, you would find that our 2024.1 release will conflict with your customization because the field already exists (yes, we are adding Promise Date to Order Header, Order Dtl, and Order Release in 2024.1 
)
2 Likes
I see it won’t cause issues as we do have a “Promise Date” on our OrderHed table and was scared there for a minute 
. When users add UD fields we have no choice on the “_c” as all those fields add to the associated UD table. I was asking about the “ACME” suffix you suggested.
I think i suggested teh ACME idea back before the _c thing was required. Now it is not so much a big deal. You can name your UD fields whatever you want, and like you observed, the _c is applied automatically. This was done for the very reason stated.
1 Like