I may have taken the wrong approach for our .600 upgrade but I spun up new servers (VMs) for it. Here’s how I got our .600 test/dev environments going. This worked fairly well. There were a few little bumps in the road but I figured those out. When it’s time to the PROD .400 to .600 I would do the same thing.
Installed .600 RL on new VMs
Copied our PROD .400 dB to a new .600 DEV dB
Added the new .600 DEV dB to the EAC
Ran the dB upgrade to get the dB up to .600
Add a new app server and deployed a .600 DEV app
Ran the conversion workbench to go from .600 to 600.10
Thats what I understood from reading the last comments, if you modify the existing app server to point to the new installation the issues happen, so creating a new one should avoid those.
Well, I had a backup, but I had to create a new 10.2.200 server to reload it to. Time consuming, but less so than creating and remembering the BPMs from scratch!
Heads-Up if you have Grid Layouts, your columns order may be jacked up, in many screens, messing with Paste Insert, Paste Update templates your users may be using.
Not sure what the reason or benefit for this change was:
in 10.2.600 they remove the LayoutXML old VisiblePosition and then they store it in ColumnFilters XML Node, and your customization xml goes from 2mb to like 4mb in size.
They don’t even migrate your old VisiblePositions to the new, but just remove it.
Maybe this has been like this, for a while and I just happen to be still on the 10.2.400.x version where the following bug was still not fully patched:
So, I am now noticing the bloat because, when you have that bug, it didn’t bloat it.
I tried it on my local 10.2.300.17 copy and it bloated like 10.2.600, yet 10.2.400.12 didn’t bloat, which works in my favor because its just junk, o well.
Maybe that’s why my columns have been through a washing machine and shuffled all over the place in 600. But then again, it removes the old VisiblePosition or doesn’t honor it, unless you move your stuff and Save Layouts again. (still a bummer).
Has anyone had any gotchas with the Task Agent? We just had an odd one where it wouldn’t start and even with verbose on the agent enabled, it didn’t log the cause. Then we made a slight change to the TA Schedule (basically trigger an update, uncheck, check a box) and the Agent started fine.
Leaving this out here in case anyone else sees anything. For now unexplained mystery.
Hasokeric, THANK YOU for detailing the need to rebuild the ARForm Data Definition and RDL’s for the .600 upgrade. We just upgraded to .700 this weekend and I ran into all of these problems with the ARForm definition and my RDLs.
I took your advice and I started with the new BASE definition and added what I needed for my custom reports to run, some modifications were also required to the data set queries in the RDL due to columns missing from tables in the new revision etc.
Just wanted to let you know you helped me and my team greatly with this post. Thank you!
Im glad folks do go back and read older posts and don’t always just ask the same question that has been answered at some point before Glad we could help!!!
I’ll add that with our upgrade from 102400 to 102700 we also had to touch on our OrderAck data defs and RDL’s, and our Bill of Lading RDL (both custom) in a similar fashion to the ARForm errors.
We have this issue in migrating from 300 to 700.23. I have spun my tires trying to figure out how the hell to fix this. It did not break and worked fine in both test environments, but for some reason when upgrading our live server I get the Error 404 on every Epicor menu item dealing with reports and the Kinetic App Maintenance. I cannot find a DB table for Kinetic, I do not have an option to DMT to the Kinetic app screen to disable for all users. The only solution is to clear the client cache and set to classic from the Settings screen.
What was the solution Epicor provided? Can you please share so others know how to fix? I don’t want our IT department to have to clear the client cache and change the settings to classic for each user individually when deploying which appears to be the only fix for this bug.
if you log in as Manager using the client directly on the server (right click, run as other user) , using a shortcut with the /shell switch, can you not open kinetic application maintenance and disable all apps for all users at least until you get them sorted?
And then recycle app server or even restart task agent to make sure everything changes?
I have not tried to set the desktop shortcut to base/classic mode there or in the Config Editor and then try to log in and launch Kinetic. The only way we have been able to make this work is by setting the DefaultFormType field on the Ice.SysUserFile to Base rather than Default. Only if you do that, or change the preferences to Classic and clear the client cache will any report menu item window launch, but Kinetic still does not come up.
As a work around we did a DMT to the SysUserFile table and updated all users at once. That still does not fix the bug as to why it happened in the first place and we still are unable to launch the Kinetic App Maintenance menu even in classic/base mode. When I have time I will try your suggestion of setting the shortcut to classic mode and see if that works.
Negative. Classic mode still results in same error 404. I have no idea why this happened in our live environment upgrade and our two test environment simulations did not have this issue. We have a work around to turn this off for all users, but still cannot suppress the annoying yellow ribbon on every menu item nor will we be able to test any of the Kinetic functionality as long as this remains unresolved. Of course Epicor support still has not assigned my case I logged last night when I first reported this so they are in no rush to help me out.
I know very little about binding protocols, but does a 404 mean you’re using http/https? I’m probably wearing my ignorance on my sleeve - but if you are, what about creating a management appserver using netTcp and seeing if you can get in that way to change your settings?
Unless your production line is stopped - in which case call your CAM’s cell phone - I haven’t known Epicor to assign cases on the weekend, and other than that the 5 or 6 cases I’ve opened this year have been assigned within a few hours. They’re doing pretty good lately.
Glad we could help!!!