Serious follow-up question …
Should the App instance be stopped before running the Data Model Regen?
(If for no other reason than to prevent people from logging in while the regen is in process)
That is what I would recommend, yes.
That is odd,
The Companny from which we bought Epicor and who installed, trained and supported us have told us that you can do a regenerate data model while users are in the system… But is is the Recycle IIS that was the action to make sure no one is running active tasks… If there is no active task, recycle!
We have been doing that for the last 3 years !!!
I guess we got lucky!
Pierre
IISRESETs makes Dawson sad. LOOK AT THAT FACE!! Please don’t make Dawson sad.
2 Likes
This has been discussed previously. See this thread for Best Practice on Data Model Regeneration.
2 Likes
Worse - I have been told the same thing from an Epicor support person in the Monterrey office…I found a polite way to say No to that idea.
@Rich is dead on.
I need more time to go on about the life cycle of the app server and how the data model fits into that, etc than I have at the moment. Needless to say - the DM regen is an app pool recycle - everything cached needs to be torn down and stood back up again on the server.
I have had some folks say they can do things while developing on a stand alone box and they can - because they are making changes that force the app pool to restart with what they are doing so it’s ‘safe’ - in the sense that the thing is automatically restarting! Unfortunately things get misunderstood when you play telephone…
I’ve been adding some custom fields lately. On Sunday I performed a regen while MRP was running, figuring if it had a problem I’d just kick it off again. When performing IIS reset it usually gives no warning. When trying to perform IIS reset while MRP was running, I did get a warning, something to the effect that long running process that go beyond the timeout window would be aborted. 10.2.300.5 at the time.
Wow, I am surprised at the lack of even basic change management going on here. You are fundamentally changing the structure of a data model whilst transactions are taking place which is massive red flag for me. Just because the system does not stop you, does not make it right.
Even doing this during arranged down time I would take a db and system backup immediately prior to making the change just in case anything went wrong no matter how trivial the change. The correct process as explained to me by an Epicor engineer was do any work when there are no users on the system, stop the app server, regen the data model and then restart app server.
You do this, something goes wrong and you break the system and you are fired, “the system didn’t stop me doing it” is not going to be much of a comeback.
Stepping back from the technical aspect, a lot of the posters on here work for US companies, many of whom are governed by Sarbanes Oxley. How on earth are you getting away with making db changes to critical systems on the fly whilst remaining compliant?
2 Likes
Simple, only answer the Auditor with yes and no, and do not elaborate, without explicitly being asked to elaborate 
By the way I know an Epicor Engineer who worked for 20yrs on the ICE Framework, yet asks the most basic questions like how to convert an int to a string. How he remained with Epicor for 20yrs is beyond me. Just because someone is an Engineer or Gold Partner, doesnt mean anything. I know plenty of ICE Certified Consultants who don’t even know how to use BAQs. Heck just an hour ago a Epicor Partner asked how to back up a database, while offering IT Services for 2+yrs… what kind of consulting shit is this 
and how is Epicor certifying these clowns?
But that aside, the right way like you said is to regen during a maintenance window, there doesn’t exist a change that must go into production “right away”. At the least do it during Lunch Time, but never during a busy time. Plus if you regen and import your customizations, most people won’t even see it until they restart their Epicor anyways (to refresh Menu Securities).
Plus if one understands the Entity Framework and what “Regen” actually does, it might click better. Epicor literally rebuilds a .dll (Recompiles) and replaces it while the Server is running. 9 out of 10 times, you will survive. That 1 time you wont. If you didn’t use Epicor and had your own Application use Entity Framework, you would have to ship an Installer to your Users to Update their Application to get your new columns. In addition - Epicor writes to the database and runs several stored procedures.
3 Likes
You shouldn’t be doing IIS Resets at all. AppPool recycle is your friend @aidacra is turning over in his office right now reading that
2 Likes
“Clowns of America International” ???
Everyone knows that’s a party school…
( Joke borrowed from The Simpsons)
1 Like
Right that’s a Recycle which is different form IIS Reset
I’m sorry but without any Epicor knowledge/training or reading manuals, any experienced sysadmin, for example a new hire with no Epicor experience, should be dubious of regenerating a “data model” when the system is up and being transacted on and proceed with caution - which is exactly what Kalvin is doing in asking this question in the first place.
The same applies to recycling IIS.
2 Likes