Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
I am moving our AX 4.01 DB without transactions over to a new AX 2012 instance. I have gotten as far the the "Launch Data Upgrade" task in the AX 2012 data upgrade checklist and have run into a problem. The data upgrade cockpit loads, takes off and runs for a little while. I see the CPU usage on Windows Taks maneger moving and the cockpit shows its processing 8 jobs and about 300 have finished. It slowly moves down from processing 8 jobs down to 7,6, 5 all the way to zero. Once it hits zero the CPU activity drops to zero percent. All this happens while no failed tasks appear and no errors popup. The process just seems to come to a stop, but the systme is fine. I click on the pause button, close out AX2012, relaunch AX 2012 and restart the upgrade cockpit and click run. It just sits there not processing with no errors.
I have repeated this process after deleting and reinstalling AX2012 and with different DBs from our AX 4.0 system. What could be casuing this to grind to a halt?
I am having a similar issue. The data upgrade runs fine for a few hours then stops. I have tried the upgrade process a few times and it stops at different points. If I select a job and click "View batch task" the tasks have a Waiting status, which doesn't seem correct. This is a link to a screenshot of the cockpit www.flickr.com/.../6923532789
Did you find a solution ?
I am experiencing almost the same thing on a AX4.
All the pre sync jobs are ok.
In the delta part, some of the jobs stand as running, but at the DB, i can see the sql-statement executing, but it never finishes.
If i take the same update methods and turn the into jobs, the execute perfectly within few seconds.
"-internal=comments -internal=nocursorreuse". Solved my problem :-)
Many times this type of long running SQL statement is caused by not using a specific startup parameter for the AOS that is running the delta batch jobs. To add the startup command, go to the AOS Configuration Utility and add the following text to the Configuration command to run at kernel startup field (not including the quotes): "-internal=comments -internal=nocursorreuse".
You can find this tip and several other best practice tips for performance in the Microsoft Dynamics AX 2012 Data Upgrade Best Practices document. Also make sure to watch the Upgrading to Microsoft Dynamics AX 2012 resource page for updated information and new documents.
For a data-only upgrade, Microsoft told us to delete our customizations in the Ax 4 system before starting the upgrade. The code upgrade process adds any custom fields to the tables, which the data upgrade needs. If you just run the data upgrade, it won't add custom fields to the tables and the process fails. I had hoped it would just migrate the fields that were in the Ax 2012 system and gracefully fail on unknown fields, but it doesn't.
This last response would be better on a different thread. The suggestion to delete customizations from AX 4 before running a data ugrade was given based on an assumption that NO code upgrade would be done in the AX2012 system, and that the AX 4 base data would be upgraded to provide training opportunity on AX 2012 features using the customer's familiar dataset. They would have no customizations in that environment. If you have done any code upgrading, you need to get your AX 2012 environment into a fully compiled state prior to attempting a data upgrade in that environment.
I too am upgrading from version 4 to AX 2012 R2.
I have a query relating to the bulk copy process in AX 2012. I have completed all tasks in AX4 but when I run through the bulk copy scripts - all process apart from the DIMENSION related ones - these appear to go to the WAITING STATUS and stay there - everything else executes and then the process appears to stop with 8 Dimension related jobs stuck in WAITING and nothing else happens.
Can anyone help me out here? Is there a log area I can check or has anyone experienced this?
This situation you are describing is very similar to another case we just had come through the Microsoft support team. The cause for it in that case was that in the AX 4.0 database, there is a table called ReleaseUpdateTransformTable which has a ReadyToBeCopied column. If you are sure that all the 4.0 processing is done, check that table to see if any rows still exist in the AX 4.0 database with ReadyToBeCopied = 0.
If you find any, then set ReadyToBeCopied = 1 for all of the rows in that table if you truly are done with the 4.0 processing. Then, the next time you push the Refresh button in the Data Upgrade cockpit within AX 2012, we go and retrieve the newly updated contents of this table, and it should clear up any dependent table issues that were preventing the DIMENSION tables from starting their bulk copy.
Kevin, much appreciated - will try this and let you know - thanks
Can you remember if you set the kernel startup options on both AOS (I'm assumming you are running the upgrade cockpit in one AOS and the batch server in another)?