If I Regenerate Data Model on our server, will that effect users currently logged into the ERP? I have to complete this as part of installing a new customization created externally, and I’m trying to figure out if this needs to be completed during off hours so users are not affected. Thanks!
I don’t believe you are able to do this with the database online.
I would not regenerate with it online if it lets you.
Plan for at least 15 minutes of regen, more if you have a large database, slow server. We’re on Prem 20GB database.
Wow!! We’re at 160GB and regen takes about 3-4 minutes. And we’ve got a bunch of UD fields and stuff.
I would not do it with anyone actively transacting as the regen causes the Appserver to recycle. I try to do it after hours, but I do not stop the appserver or DB, nor do I terminate my MES station connections - and I’ve never had any issues. knocks on desk
2 Likes
For some counterpoint I haven’t done an off hours regen since before 10.2.XXX. The only thing I have had to do is work with impacted functional areas. So for example if I add a column to OrderHed, from the time I add the column in UD Column Maint to the time my regen and recycle is done I don’t want them entering orders. I’ll email and say hey between 12:00 and 12:30PM today refrain from entering orders. Our scale allows me to do this, might not work everywhere, but from a technical standpoint mid day regens and recycles have never been a problem for me.
5 Likes
You’re right ours is only couple minutes too =) I rounded way up. I assumed that everyone had larger db than i do and it would be linear.
I’m not sure what exactly happens during regen, I normally use it when adding UD fields and just take it offline, or during upgrades, which it will already be offline.
Here are the steps from KB0038324
- Log into the your Kinetic/ERP Application Server.
- Stop the Task Agent Service
- Stop the Epicor Kinetic/ERP AppPool
- Regenerate the Data Model
NOTES:
You must keep the ‘Data Model Regen’ form in focus (selected at all times while the regen is running in order to receive the message “Data Models generated successfully”).
Do not continue with the steps below until you see that message pop up. Depending on system resources, this process may take upwards of 30-45 minutes, so please be patient.
The “Work in progress…” animation will sit there and run the entire time that the screen is up.
- Start the Epicor Kinetic/ERP AppPool
- Restart the Task Agent
- Log back into Epicor Kinetic/ERP
1 Like
I regen all day every day with 600 users logged in (been doing that for 5yrs). No issues. BUT it is best to do it outside of hours. Users get choppy connection in 10.2. I am unsure about Kinetic and how Rest will act when you do it during the day.
For sure dont do it while MRP is running or any scheduled process 
2 Likes
Another note,
I’ve forgotten to Regen after adding UD fields before and it has caused random issues and exceptions (usually related to the table i’ve messed with).
We are at 900GB I think it takes about 3-4 min as well.
When you regen, it is just a file update on the disk.
After regen is completed, file is uploaded into DB.
Until you restart app pool, you don’t use new file from DB - it is downloaded on app pool restart.
After you restart app pool, clients should relogin, otherwise customization changes from the latest data model would not be applied
5 Likes
Nice! I always do it off hours just cause I worry, but it’s obvious you can do it whenever based on what some of the people are saying here.
I do regen whenever necessary. (ud-fields added would be the major need)
But before I perform a Recycle IIS, I verify if there is any process currently running…
If none are, I Recycle.
Then restart the EpicorIceTaskAgent otherwise our printing is not working…
Pierre
1 Like
IIS Recycle does that too, so not a complete start/stop is needed. Unless it changed in Kinetic. Just speaking based on 10.2.x
I don’t remember the details but at one time per @aidacra IIS Recycle vs App Pool Recycle was a no no. Something with clean up but I don’t recall? I forgot in my other post too if you are running a different app server for task agent don’t forget to recycle that bad boy too. Generally after recycle I log in as quickly as possible so that BO is already “warmed” up for folks.
Again I do it for 5yrs, 600 users - always worked Ill take my experience over theory. I mean that in a good way I just never had an issue, ever, ever ever ever and I regen like a mad man on steroids daily just for fun sometimes 
We have multiple App Servers, Task Agents and Report Servers - yes all need to Recycle.
But again im just being a bit sarcastic; Just because I was lucky 900 times doesnt always mean its right.
If Epicor recommends an after-hours approach Id follow it, or don’t at your own risk.
2 Likes
I heard an opinion that recycle could have exisiting DM file locked and in this case reload does not happen. Probably it is not often, so you don’t see the problem.
Lets review a few Tech Details related to Data Model Regen.
The Data Model is the Software definition of the database Schema and the time to build and compile the data model is directly related to the size of the database schema, the processing capabilities of the machine running the Regen, and the table size (number of rows) on the table(s) being extended - this step is more expensive on large tables being extended for the first time. As the Epicor Schema definition is far larger than the UD extensions added, your UD additions will have little impact on that element of the time required. For mature implementations, extending a large table for the first time will also be rare so for most of you, the horsepower of the machine doing the Regen is the major factor in the time taken to regenerate the DM.
Extending a table for the first time can cause data corruption when the system is active during the regeneration - hence the recommendation that the system is inactive during a Regen. Data corruption occurs when the database schema has been extended, but the matching Data Model is not yet active. If a record is added in that time window, it is orphaned as we will not create a Record in the UD table (DM doesn’t yet know the UD table exists) and our SQL retrieval logic selects the Epicor record via a Join on the UD Table. Orphaned records are in the DB but will not be retrieved by the Epicor software.
The Data Model is generated and then written into the database but it is only activated when it is pulled from the database and written to the AppServer file system. Pulling from the DB and writing to the file system occurs early in the AppServer startup. If the Data Model DLL is active and in use, it cannot be replaced by the AppServer as it starts and the older one will remain active even for the new AppServer instance. That scenario can occur on an AppServer Recycle where the IIS Default is to leave an active AppServer instance running and start a new AppServer process. New inbound requests are sent to the new AppServer and the old AppServer is killed off when it is no longer Active. Since a Recycle does not guarantee that the new Data Model will be activated, the recommendation is to Stop the AppServer/AppPool, Regen, and then Restart the AppPool.
So… you can be successful with a DM Regeneration on a busy system but you should only do it on a mature environment and I would not do it on a load-balanced environment. There can / will be data anomalies as the Client and Server can have a mismatch, but the anomalies will be very subtle and of no real consequence.
10 Likes
Thanks for the breakdown Rich!
4 Likes
@hkeric.wci I have also always done this for years without any issues, but maybe we are just living right. 
1 Like
Nice Olga 
1 Like