10.2 Data corruption risk on data model regen

Hi, when we were migrating from 9-10/10.1 we were warned that we shouldn’t do data model regeneration when there are users transacting in the system or else we could have data corruption issues.
Recently upgraded to 10.2 and going through the documentation I can’t find any of those warnings.
We’re basically running 24/7 so it’s getting difficult to find times when no one is transacting so we can do a data model regen for adding UD fields.

Can anyone comment on how accurate the risk of data corruption is?
Based on what I’ve gleaned about how it works I expect we’re being overly paranoid but I’d still not risk corrupting the database if we can avoid it.

The data model regen is literally changing the schema of the database, so you don’t want users transacting on the Part master table in the middle of users changing something with Part master records.

This is one of those prevention > cures situations.

If you don’t have a maintenance window at least monthly to complete routine maintenance, upgrades of the ERP, Windows updates then you need to fight the business for those windows because maintenance is important.

Alright, what you’re saying makes sense. I don’t know how much I agree with your analogy though. You’re not actually modifying the Part Master table. You’re modifying the Part_UD table and recreating the view/stored procedures that references the table.
There are scenarios where I could see that causing issues. A user inserting a new record in a table when a _ud table is created for the first time for example. Something like that should be rare. Adding a column to an existing UD table though I would hope it wouldn’t screw things up that much.

We do have month maintenance windows but once a month can be a long time when you’re dealing frequent deployments. Currently in a worst case we kick everyone out for a time but as we expand to the rest of the organization this is going to become more difficult.
How does Epicor handle this for SaaS clients?

They complete them during monthly maintenance windows.

1 Like

From what we were lead to believe it’s a shared database with multiple clients. That’s why there are various restrictions for cross company development.
Wouldn’t the regen be done for all clients in that database?

I’m not trying to be a jerk, but as we’re expanding our footprint we’re running into concerns about maintaining availability for upgrades and maintenance. Question has been raised about how this is handled for the SaaS/cloud clients.

Correct.

Sorry if my earlier comment wasn’t clear. For Multi-tenant (multiple customers per database) they complete data model regens during the planned maintenance windows that we have built into our Cloud offering SLAs. For Dedicated-tenant (one customer per database) they complete them on an agreed upon time with the customer when there won’t be users in the system.

Thank you for clarifying. Having it as part of the SLA makes more sense.
We’ve been fortunate to get the organization to buy in to a maintenance window early on. Don’t expect that it’s going to be easy to hang on to once we have more facilities on board but this should lend some weight to my argue.