Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2023 Release Wave 1Check out the latest updates and new features of Dynamics 365 released from April 2023 through September 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | All TechTalks
Year end closing taking long time in ax 2009, It is running since last 88 hours.
Can any one suggest, how to speed up?
Can anyone replaced "insert" to "insert_recordset" in LedgerTransferOpening class, which used in year-end closing process or any other solution.
I have written a blog about rebuild or recalculation of balances. This blog was written for AX 2012 and talks about some performance issues and mitigations: Rebuild balances in AX 2012 (dynamicspedia.com)
Note that the way how to recalculate the balances after deleting previously created opening transactions is different between AX2009 and AX2012. It might be that some logic in AX2009 was causing more delays. I can remember I did a customization in the past to limit the recalculations to one year or one period only, but that was on an AX4 environment. I think also in AX2009 it will recalculate all balances and not only for one fiscal year.
I don't have a running AX2009 environment to check the logic and give a direct full recommendation. I do hope the blog and my comments above will give some starting points to investigate for similar issues and probably change some logic to improve the performance by e.g. change the recalculation to calculate for only one year.
We had the same issue and fixed it.
Make sure you dont have the "optimize for unknown" flag set on the SQL Server (4136).
This will surely park you AX and make everything run slow.
Often it has been implemented to fix parameter sniffing, but it is way better to identify the few places you find these issues and fix it by changing that code, index turning or simply add a plan guide (we have about 15 plan guides on our database and are not seeing these issues anymore).
If you don't have the 4136 flag set (check by running DBCC TraceStatus() on the database )
Our result on a well functioning, fully upgraded AX2009 with SQL Server 2012 SP4
All enabled globally
Then you may have to look at the numbers of threads it can start up.
But first. Let me know what flags you have enabled.
Business Applications communities