Best way to recycle an AppPool?

When I hit Recycle IIS Application Pool in Epicor Admin Console, will that cause end users any problem other than a temporary freeze for a few seconds?

I have been doing this in a live environment for a customer as I add UD columns so that we can keep the workflow moving with creating BAQs and Dashboards on these UD columns instead of waiting overnight every time that we need to add or change a UD column. So far no one has complained and I left my Epicor client open to see what happens and nothing happened. I think it’s ok, I just wanted to get a second opinion on recycling to make sure it doesn’t cause unexpected problems.

If recycling an App Pool in a live environment is a hard ‘no’, then what approach does one take to keep the UD to BAQ to dashboard workflow moving instead of waiting overnight for every change?

If you do it while the application is in the middle of Posting an Invoice or Saving… you could technically speaking sometimes caveats galore cause issues or data corruption.

You should do your development (yes even BAQs) in Pilot or Test then move them to production overnight … (if you want to be a good citizen)

Is it a hard no? … cough we’ve all done it cough but you do take some risk you know… think of it like not wearing a mask

You’ll probably be ok… but you might not and is having swiz cheese lungs I mean corrupted data worth the risk? :stuck_out_tongue: :mask::mask:

So… wear a mask damn it! I mean … develop in Pilot!

2 Likes

I get what you’re saying and see how that process would be ideal. But what happens when you do work in Pilot, you test and it seems perfect to you, but when you move it over into Live the end user finds a unique scenario that you did not test and it breaks? Just tell them they have to wait until the next day? Ok sometimes but not an option other times.

I am wondering if there is some other creative method to work around this. I was thinking about setting up another AppServer on the same database and doing work there so that I can recycle at any time and only impact me, but the only way to get it fixed for the end user is to recycle their app pool, no?

That would still be an issue because when you add a new UD Field it breaks things (right away) in all AppServers pointing to that database since the zDataTable and zDataFields are modified immediately (regardless)

In your scenario you shouldn’t have to add another UD Field (one hopes)

Also you should have your users fully test the modification in Test before moving to Production.

If an issue is found that is so grave that it can’t wait, then you should make your changes notify everyone to get off the system and then recycle…

But I wager you’d be hard pressed to find this situation often if you are exercising at least a modicum of standard development practices

You should be developing in Pilot and testing it your self, moving it to Test having the end user thoroughly test it and then deploying to production. Yes it is tedious but better than corrupting your data…

And again if something does happen in production that warrants a recycle then kick everyone out for the 10 minutes it takes to do it.

4 Likes

Thank you for this excellent info. What is zDataTable and zDataFields? Those are totally new to me.

When you create a new UD Field it creates entries in these tables which are used throughout the application (for things like listing the tables in BAQ’s and more)

2 Likes