Upgrade

You may encounter this error when launching the Live Preprocessing or the Delta processing scripts, for the AX2012 Upgrade checklist in AX2009, even though you have successfully completed the Upgrade Readiness scripts.

Error:

We have encountered this error in the following scenario:

• Ran the Upgrade Readiness scripts. All scripts completed fine.
  
• Ran the Live Preprocessing scripts. All scripts completed fine.
  
• Opened the Upgrade Readiness scripts form to review the results; and closed the cockpit form without running the scripts again.
  
• Tried to launch the Delta Processing scripts > encountered the error.
  

Cause:

When the Upgrade Cockpit is opened, it loads all the scripts, for the current stage, into the ReleaseUpdateScripts table. When the form is closed, it checks whether all the scripts have completed. If they have, the logic deletes the records from the ReleaseUpdateScripts table. The records in ReleaseUpdateScripts do not get deleted if the scripts, for the current run, have not completed.

The reason for the error was that when we closed the Readiness cockpit, the records in the ReleaseUpdateScripts table did not get deleted.

Solution:

Delete all the records from the ReleaseUpdateScripts table.

We have faced an interesting issue with the upgrade cockpit, executed in AX2009 as part of the AX2012 upgrade. There appeared to be a disconnect between the upgrade cockpit and the batch job – the cockpit showed the script as finished, while the batch job showed it as failed. This turned out to be an issue with the upgrade framework logging.

Error:

The cockpit shows the job as ‘Finished’:

However, the corresponding Batch Task is failed:

Cause

In this particular case the table in question, DEL_AddressStateUpgrade, was in fact populated properly – providing the indication that the upgrade script has completed successfully. Therefore, it appears the cockpit status was in fact correct, while the batch job was not. So what was going on?

It turned out the issue had to do with the way the upgrade framework monitors the state of the scripts’ execution. As scripts are executed, their statuses get written to the ReleaseUpdateControlData table. This table tracks the last record executed by the script. This information is stored in the ControlData container field, and typically holds the RecId of the last record processed. This enables the upgrade cockpit to pause, resume and restart, making sure each record is processed only once. Every time you re-open the upgrade cockpit, all of the scripts are added to the batch job, regardless of their status. This means that each script is re-executed every time the upgrade cockpit is re-launched. The ReleaseUpdateControlData logging is what makes sure that only the data that hasn’t processed previously is operated on, each time the script is executed. (By the way, this means that you can’t simply update the batch job status to ‘Complete’; nor can you update the records in the ReleaseUpdateScripts table – as these statuses do not prevent the scripts from re-executing).

What caused the issue in our case, is the fact that for some reason the record in the ReleaseUpdateControlData, for the script in question, wasn’t updated with the correct ControlData (last record ID). The RecID stored in the ControlData field, was smaller than the greatest RecID in the source table (AddressState in this case).

Solution:

1. Delete the ‘corrupt’ record from the ReleaseUpdateControlData table
   
2. Delete the script’s target tables – in our example the tables populated by the script are ‘DEL_AddressStateUpgrade’ and ‘LogisticsAddressState.’
   
3. Re-launch the data upgrade cockpit – which reruns the upgrade script successfully
   

*We have seen a flavor of this issue, where the ReleaseUpdateControlData record didn’t get written at all. The solution in this case is similar: delete the target tables, populated by the script and rerun the script. This procedure may need to be executed every time prior to re-lunching of the cockpit, as from what we saw the record never got created for the script in the ReleaseUpdateControlData table. Manually creating a record in this table didn’t resolve the issue.