Adding UDField - Procedure

Epicor ERP 10
1

Currently, our steps for adding a UDField to E10 is:

  1. Add the UDField in Extended UD Maintenance

  2. Run Epicor Admin Console as Administrator

  3. Regenerate the Data Model

  4. Stop Application Pool

  5. Start Application Pool

I could be wrong, but I believe regenerating the Data Model while someone is creating transactions in Epicor could easily corrupt the db. So I was thinking that steps 4 and 3 should be swapped. Stopping the application pool would force everyone out before regenerating the data model. So this begs the question: is it harmful to regenerate the data model while the application pool is stopped?

2

It is not harmful and that is typically how I prefer to do it. if you have multiple app servers keep those in mind as well.

3

I was told by my Consultant who installed Epicor that Regen DataModel could be done while users are using Epicor. The steps following that, would be Recycle IIS and then restart Task agent . It is the recycle IIS that I need to verify if any current transaction are occurring, visible under Monitor…if there is none, I recycle.

So far no harm known… :wink:

But is this really the good way?

During developement we do not want to wait off peak hours, or to have all users out of the system every time a regen is needed… ! It currently happens quite often…

Pierre

4

I think the keyword is could. Definitely not a best practice. Also, recycle sometimes works and sometimes does not depending on what is going on in the environment and version.

Are you developing live in Production? Typically you would be in a separate environment and selecting a good time to promote these changes to Production and ideally during a maintenance window or off-peak. Once again, best practices, but when you abide by these you will contribute to a stable production environment.

5

Actually we do our dev in test, but since we are a 24h shop there is not much times where we can ask users to stop using the systems…in order to implement our changes… but yes we do our best to use lunch times/breaks period if possible…

6

Best practice on this is:

– Stop the Task Agent(s) (if a task agent is running it can keep the AppServer alive)
– Stop the AppServer(s)
– Regenerate the DataModel
– Start the AppServer(s)
– Start the Task Agent(s)

The DataModel is stored in the Database and as an AppServer starts it moves the DataModel to the “Assemblies” file system as specified in Web.Config. Having an AppServer running with an out-of-date DataModel can result in data corruption - particularly if a UD Table is new and does not exist at all in the currently active DataModel.

9 Likes
7

It was recently shared with me (experienced onsultant) his steps for Regens. In addition to Richard Riley’s trustworthy, concise and expert Best Practice steps above, he included “good idea” stuff to also do, things such as re-deploy all user dashboards in Dashboard Maintenance…

  1. I am wondering if this is either urban legend, something that used to have to be done, or special edge cases etc. Are there other steps that Admins include as part of the Data Model Regeneration Process and for what reasons… is it due to your version, your customizations or environment etc.
  2. It was also shared that I could skip running the Regen step above on the other appservers if I instead copied the two files from our “…/Server/Assemblies/” folder named “Erp.Data.910100.dll” and “Ice.Data.Model.dll” to each of the other respective Appserver’s folders. Is there any issues with this approach (I have not done this and instead been running Regen server by server in sequence starting with the Appserver with the Task Agent/and ICE Task Agent Service running on it, and then each of the other Appservers and then restarting the Task Agent at the end.

Thanks for any additional guidance with context of the ‘why’.

Our current Architecture: currently Epicor 10.1.600.21, Separate SQL/appserver (for special DB intensive processes only), Appserver1 (User load balanced), Appserver2 (User load balanced), Appserver3 (Task agent and Manifest, EDI, EDA synch), load balanced Parallels Farm for client access apps). Full licenses = 151, MES = 30, Manifest workstations = 72

8

Henry - The Data Model Regeneration is generally independent of any other “tasks” - the downtime required when doing the regeneration correctly is a convenient time to do other maintenance activities but other than some possible edge cases, I can think of no reason to do other work.

The Data Model Regen performs several activities but they only need to be done once so there is no reason to execute it against multiple AppServers and there is also no reason - if the proper steps are followed - to copy files around.

A Data Model Regeneration has two distinct steps -

  1. SQL database Schema modifications
  2. Entity Framework Data Model creation and compilation

The SQL component includes:

  • Creating New UD Tables
  • Creating New UD Columns
  • Deleting UD Columns removed from the UD Table definition
  • Synchronizing the data records in the UD Table with the data records in the main table

The software component includes:

  • Generating the C# code for an ICE Schema Data Model and a for the ERP Schema Data Model
  • Compiling the Data Model DLLs
  • Writing the Data Model DLLs to the database

If the Best Practice steps I outlined before are followed, the new Data Model will be pulled from the Database by each AppServer as it starts, so there is no reason to Copy files from one AppServer to another.

Also related to the Best Practice steps - data corruption can occur with the Data Model regeneration if you do not stop all the AppServers prior to the Regeneration process. Corruption occurs when a new xxxx_UD table is created (no UD Column existed for the Table previously) and a record is then added to the main table under the old Data Model. When that happens, the main table is updated correctly but no record is added to the UD table as it does not exist in the old Data Model. As the bulk of the Epicor SQL processing does a join from the UD table back to the main table, it will appear that any new records added under the old Data Model did not get created - not having a UD table record has essentially orphaned the main table record.

1 Like
9

Thank you Richard!! I so appreciate your definitive explanation of the actual processes underneath and clearing up the debate whether to Regen during a maintenance window (all users out, Task agent stopped, appservers stopped).
:star2:

1 Like