These are famous last words with worlds of unstated assumptions. I have seen this same Infor support suggestion used for APARs (Infor’s Single Fix for SyteLine) that include only a simple non-critical stored procedure, versus APARs which require a test utility server, and FormSync to be run.
Here is a list of the critical small print –not always mentioned by the Infor support representative:
- You should apply APARS to a Test Environment instead of applying this directly to live.
- If this includes any form object updates, and if you have any custom forms, you should assume that you need to run FormSync. Otherwise – your custom forms may not continue to work. Even if the forms seem to work, your custom forms will not have any of the fixes in the APAR if you didn’t run FormSync.
- If this APAR includes any class (.cls) files, you need to have a test utility server. If you try to apply this to test databases, but you don’t have a separate test utility server – you could break your live SyteLine.
- If this APAR includes any report (.rpt) files, you need to have a test Taskman server (usually part of your test utility server.) Otherwise – if you try to apply this to your test environment, you will overwrite your live reports.
- If you or your business partner have modified Infor stored procedures or IDOs, you may lose your changes.
- If you have business partner add on products – you may need the corresponding fix from the business partner. You need to have any corresponding fixes applied before running FormSync on the test environment.
Remember – there is no uninstall for an APAR. It is much safer to assume the worst than to try to deal with the consequences of applying a large APAR directly to your live environment.
Does anyone have any horror stories of what happened when they applied an APAR without reading the small print?
