We are testing upgrade from 905702a to 10.1.500.15
We have several customizations with ud fields that were used from base tables, eg POHeader.Character01, etc.
It’s as if some of these ud fields converted ok and then others didn’t. See screenshot. I don’t have all of my UD fields available for binding now, there’s skips in sequential numbering from the Character07 straight to Character10.
I’m trying to determine how best to deal with this moving forward. I think i can add the missing UD fields for the lost ones via Extended UD Table Maintenance. It seems like then i’ll have some _c ones and then others that aren’t. Seems weird.
Has anyone else dealt with this and have any recommendations on best practice?
if you’ve never populated data in the column it may not come over. If you really need everyone to migrate over (even though you haven’t stored data in it before) you can create a single ‘seed’ record by using DMT or another method to populate every column with a value for that particular UD Field set on a given table. TBH, it just adds space to your DB porting over unused columns when you can so easily create a purpose built and functionally labled myfield_c column going forward when you need it. Having them sequential is just symantics. I seeded tables in my first migration and if i had to do it all over again i would not have done that. Just my 2 cents.
We have experienced this same issue, and it was as Rob describes. UD fields never populated don’t convert in some cases. This becomes problematic when those fields are referenced in customizations, reports, BAQ’s, etc.
Again in alignment with Rob’s recommendation, our solution was to add a stage during the migration process before the E10 schema changes to populate dummy SEED data in the relevant UD fields. After the Migration is complete, we reset the records back to original value.
We have also seen an instance where UD Fields get converted to the wrong datatype…Example: If the first record in a table has a numeric value in a character UD, the upgrade database would have the _c column as numeric datatype rather than character. Our solution in that case was to convert the numeric to their text equivalent… 10 becomes TEN
The dropping on unused UD fields was by design (You would not believe the db size and performance improvements we found by doing this).
I have not been in that area for a while, have you submitted bugs on those? Call numbers please if you are still struggling and I’ll see what I can do.
Dropping unused UD’s by design was absolutely a great performance move. I am personally a big fan of that change!
Clients just don’t like being told they need to pay to fix all the customizations referencing the unused field
Unfortunately, they tend to want to lump this in as an Epicor upgrade problem rather than the business process failure or customization design problem it really is.
Well if we missed a dependency during the migration I want to know. The intent was to help you, not cause a problem. Make sure you poke us to look into what we missed…
The upgrade to 10 has been well talked about on this and the EUG forum. There is lots of advice from people who upgraded what seems like ages ago now.
The is a step in the conversion where you can alter an xml to include any columns that wouldn’t otherwise be created because they had no data in them. Means you don’t need to add dummy data at any point. Shout if you need me to identify exact location of this xml file. Stephen Edginton has posted on this topic previously.
Ah missed that feature was added. Not surprising since Stephen is all over making the upgrade easier. He would probably have chimed in if he was not on his honeymoon
If you could provide location and when to update the XML to provide UD fields as I need, in regards to conversion timing, I would be very appreciative. I cannot find any such document myself, hunting and pecking around here
This tossing out of any UD fields that contain no data (i.e., despite the fact that they are placed on customizations, in dashboards, queries, reports, bpms, etc.) is KILLING us in regards to trying to get our tools back to working. I really really really wish that if it was desired by Epicor to ditch them, user coulda chosen to do so or not.
Nancy -
We always struggle on the usability side of these kinds of changes. On one side it’s just do it, you are the experts so don’t ask. On the other side people want full control in an expert mode.
It sounds like we stabilized on the just do it with an override feature (missing the use case(s) mentioned above). If you want full power, explicitly override that in the configuration.
Recommendations on improving the experience? Maybe an ‘Advanced’ button when executing the upgrade to enter the fields there?
@Bart_Elia, would you be able to tag Stephen on this post, as I don’t seem to be able to.
Nancy, I’m sorry I can’t locate the file on my server and searching the forum hasn’t given my any results. It does exist though, I’m sure I didn’t dream it!
I’m experiencing the same thing with OrderDtl.HasBeenConfigured. This field is populated in E9, but does not appear in E10. Was this field also intentionally dropped?
Thanks.
aidacra
(Nathan your friendly neighborhood Support Engineer)
14
We include any schema change (new, removed, changed) columns and tables in the built in application help.
aidacra
(Nathan your friendly neighborhood Support Engineer)
16
In E10, one can query the table erp.OrderDtl for fields LastConfigDate, LastConfigTime, and/or LastConfigUserID to determine if it was configured. Based on my reading of the SCR that obsoleted HasBeenConfigured, those fields will only be populated it if was configured.
Any chance either of you can hook me up with the instructions or the fella who knows how to hit an xml file midstream on upgrade to get my required UD fields to get created on upgrade from 905702A to 10.1.500.15 despite that fact that these UD fields hold no data?
Thanks very much for your consideration!
Nancy
aidacra
(Nathan your friendly neighborhood Support Engineer)
19
Rob’s suggestion is by far the simplest (and actually supported); populate at least one row per table with a non-default for the data type for that column for each _UD field you wish to bring over before migration. Afterwards, the “seed” values can be reset.
I’ll pester Stephen when back. He’s a peer on my team so when he’s back…
I am actually curious what toys he has been doing. I have been too busy with some things for Insights 2018 to look at some of his efforts which look wonderful from a distance. Very excited at some of the things for 2017 to show all and even more excited about vNext…
“advanced” option to be allowed to enter to keep particular fields would’ve helped us alot here.
