Epicor Admin Quick Tip: Regen After a Refresh
I once had an Epicor go-live brought to its knees by an administrative snafu – as cutover weekend neared, the Epicor admin refreshed the Epicor production environment with a copy of the Epicor Pilot database. Such a step is not uncommon in an Epicor cutover. But this had not been the first time that a production refresh had occurred, and there had been subsequent customization activities developed since the last Epicor database refresh. As such, there were several Epicor user-defined fields that were present in the Pilot database but new to Production. This small discrepancy created unexpected hardship to all involved.
Chaos to Resolution in Epicor
The net result for the Epicor core team that was cutting over to the new system over the weekend was a litany of cryptic Epicor error messages, abysmal system performance, and a near mutiny by the Epicor user community. After roping in a few Epicor administrative experts, we were able to discern the discrepancy, regenerate the data model, and move beyond this hurdle. But the memory of that small Epicor system administration rule-of-thumb gone wrong stuck with me, long after the project had wrapped up.
One reason for this latent memory is that it finds itself refreshed by new instances – just recently, I found an end user reaching out to me over some cryptic errors in a test environment, an Epicor environment that had just recently been refreshed from a seed database. My first question: “Did you regenerate the Epicor data model after refreshing the Epicor database?” Problem solved, albeit this time, without the pitchforks and torches.
Echoes of CRC Errors
Does this issue sound familiar? For those of us whose Epicor administrator duties go back to Epicor 905, Epicor Vantage, or some earlier Progress-based version, these issues might be likened to the familiar “CRC errors” that once plagued our Epicor custom solutions. In that case, a field had most often been added to the database, and that field caused an existing Progress-based compiled assembly to malfunction. The table structure at the database level did not match the table structure at the application level, and chaos ensued.
Sometimes, the resolution to an Epicor issue is simple. In this case, a simple Epicor admin policy would be to regenerate the data model when refreshing an Epicor environment. This ensures that you will not have any mismatch with your Epicor UD fields, and that the users can jump in without issue.
This is especially true in an environment where custom solutions are being developed, as is the case with many Epicor implementation projects, where changes are most often occurring. This can also be the case in Epicor projects that are heavy in the use of the Epicor Product Configurator module, or longtime Epicor customers who have undergone a significant amount of Epicor customization.
Post-Model Regen
Now that you’ve regenerated the data model, don’t forget the subsequent step of retrieving a copy of the Epicor database’s data model, so that the application server in question can store it locally, for use by the application itself. At a minimum, the Epicor admin should recycle the application pool for the application server instance in question – this is accomplished from the administration console. Now, I’ve had some administrators tell me that it is preferable to start and stop the ERP application pool, rather than simply recycle it. The difference between stopping and recycling an IIS application pool demands its own article, so I will stop at mentioning this controversy for the time being, without discussing its resolution.
Epicor Cutover Success
The art of efficient Epicor system administration often boils down to steering clear of preventable pitfalls. The instance described here serves as a prime illustration of a minor adjustment that can avert substantial issues. By ensuring the proper regeneration of the data model and taking the necessary steps to maintain database consistency, ERP administrators can fortify their systems against disruptions.
Do you need help with your Epicor cutover or are you looking for more admin tips?
If you find yourself seeking guidance in the realm of ERP administration, don’t hesitate to reach out. Our Epicor Kinetic consultants can assist you in navigating the intricacies of your ERP environment, ensuring smooth operations and enhanced productivity for your organization. EstesGroup brings your company functional, technical, and custom solutions for Kinetic ERP. Manufacturers will benefit from our full-suite of services and solutions, including on-premise expertise and 24/7/365 IT and ERP consultants. From third-party integrations to private cloud and hybrid cloud managed services, Estes provides everything your team needs to succeed before, during, and after go-live.
