So, for adding UD fields, my process in old versions has typically been:
Add the fields to Extended UD Maint when I come across them
The tables will show out of sync, but no issues elsewhere
Come Sunday, regen the data model to add them to the schema
This was nice because I didn’t have to keep a list of the UD fields that needed to be added. I could just add them as I get the requests and then regen the data model during our maintenance window on Sunday.
Now, on 10.2.200.11, I tried to do the same, but the moment I added a new UD field to the JobOper table (which already has existing UD fields), all of the reports that use an RDD that has the JobOper table started erroring out complaining that the UD field I just added was not in sync.
Why are they being added to the RDD before the data model regen?
Do I have to keep a list and add them all Sunday morning before I do the regen, because that would be rather inconveniencing.
Before you had to run “Update Schema” in the actions menu which modified the tables… that feature was “automated” so my guess that’s where your issues are coming from.
This has given me issues in the past. So I don’t do that now. Not sure what versions but I’m pretty sure it was back in the 10.1 days. Now I just add them at the same time I am doing the sync. It would be nice to schedule it, (I supposed I should learn how to do the command line version so I can)
Hmm good point… I’ve ran into this issue since that started changing… Maybe it only happens in certain areas? I’m sure @Bart_Elia can provide some insight.
In SaaS, I schedule time with Epicor and enter the fields about 15 minutes in advance and then they do the Rebuild when I contact them and they do the Model Rebuild and App restart.
Hmm… will have a chat with the reporting framework team. They are trying to ease some workflows - we are listening and trying to help so a lot of focus on things in the area coming soon ™. Ticket obviously please!
FYI - back in 10.0 we allowed the db sync at a different time than the data model regen change. That caused a lot of heck. We collapsed the ‘sync’ in the UI into the regen process. One less step, no gap in having model and schema out of sync which caused data issues in 10.0. The workaround is you should immediately do the regen after sync back then.
I wonder if the reporting automation is looking at stage meta instead of physical schema. Definitely ticket!
I got burned by it too! Added a couple of fields to SalesOrder table. I thought, oh yeah, I’ll just get it ready for the Regen this weekend. One less thing to do. That was until my coworker was getting tickets saying reports weren’t working. I ended up removing them and doing it all during a quiet time.
Is now a bad time to bring up the fact that Epicor support - both online help, and support personnel - say it’s okay to run the Regen Data Model while other users are active, and to just wait to restart the IIS?
[ slowly backs out of the room ]
EDIT:
I do not endorse this course of action. I’m simply stating what has been discussed before.
This change was made to make the process of adding columns from extended UD tables to Report Data Definitions (RDD) easier. Also, to clean up some issues with the syncing process. If I am not mistaken, this change was introduced around the 10.1.400.x time frame.
Report Data definitions are based on the same table that stores the column and field attributes for the system (including Extended tables and columns), which made it a logical change from the development perspective. The Data Model Regen is really making the schema change to the ERP database in SQL Server. I understand that this change will have you change your process, but I do not see that there are any other options.
Can I suggest an exercise Bart? Can you secret shopper service as a customer so you can get a feel for what service does? You suggest a lot on here to open a ticket, and I get why you want a ticket opened. But as a customer, the answer of “it’s working as designed” and “let me refer you to a paid consultant” or “if you can’t give me the click by click steps to create the error, I can’t do anything” are pretty defeating. My general rule of thumb now is, if I can’t recreate it 100% every time, I won’t call. And even then, if I don’t have at least some idea of what I think is wrong, I still hesitate to call.
I’m not trying to knock service, they have a very difficult job, and there are a lot of customers that have varying levels of expertise (and lack thereof) that makes their job thankless. And they do help in most cases where I choose to call.
BUT, I think it would be a worthwhile exercise to pick a difficult case, explain that to the service person on the phone with only the information that an average customer would have, and see how it goes.
Oh I ‘secret shopper’ a bit all the time in my own way
As to the issue, they are probably pulling info from a KB article. THAT’s what I am trying to track down.
I reread the thread and realize that did not come across. Trust me I love my interactions with our support staff. They are hungry for knowledge and I try to keep them updated. I did the 800 hotline thing back in my early days and I’ll never forgot it. They need data and guidelines. It’s a constant battle for anyone who has worked in IT they all know.
I also get into a habit of dealing with certain ‘regulars’ up here who know that and the process of packaging up a question and submitting. For that, I will take the reminder and kick that not everyone lives that daily.
Thanks for the elbow to the side for that reminder.
