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.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
Hello community members,
I know for the fact, that SQL 2017 is NOT supported with any update of AX 2012 R3.
But unfortunately, we had a crash in our physical servers and IT created cloud environments with SQL 2017.Users started using the system and later on, when the reporting and MR components were being installed we came to know about the version issues.
Now, We are having 2-3 minutes delays in PO and SO postings like confirmation, receiving, and invoice posting.
Recently, users are saying that some of the posted invoices are removed and the PO goes back to RECEIVED status.
Now, we are setting up a fresh environment with SQL 2016. But the problem is to move the transactional data of 2 weeks from 2017 SQL back to 2016 SQL.
Any suggestions on the above-mentioned scenarios?
1. To make performance better and stay with 2017 SQL. (Which looks quite impossible)
2. How to roll back to SQL 2016 with an updated database in 2017 SQL.
The delays can be caused by incorrect SQL settings. You can start monitoring what are the bottlenecks. Have you verified if the TempDB size is initially big enough? If this is a default value with settings for small growth increments, then this might be the issue. Have you set all settings, like 'Max degree parallelism' and trace flags? Are you using fast SSD drives? You can find a lot information about SQL performance tuning for AX 2012 on the internet. One example: AX database tuning and maintenance - How to keep it healthy - DAXRunBase
I'm not sure if you can go back to SQL 2016. If the database is running on SQL 2016 compatibility, you can try to restore the database on a SQL 2016 environment.
It is worrying to me that you mention that posted invoices gets lost. In both ways, performance improvements or go back to SQL 2016, you have to investigate why this happens.
Thank you Andre,
I understand that the SQL settings can be incorrect. We have checked the TempDB and put it in an additional drive.
We have retail channels and a huge database. At the moment the autogrowth of TempDBs is set to 300 MB and the max size is unlimited.
I am reading the article by Vilmos. Looks great.
FOr moving back to SQL, simple backup restoration cannot happen from a higher version to a lower version.
We have tried SCRIPTING. Database export was done but now while doing the import in 2016 we are getting errors.
Posted invoices getting lost, never happened before. Just one user reported this. Moreover, a simple click on the workflow submits button takes 1 minute 50 seconds to popup the submission dialog.
I would suggest to start monitoring SQL performance, but also hardware resources from the AOS and SQL machine. Also check if it can be caused by some latencies between AOS and SQL and/or Client and AOS.
We are monitoring SQL performance. Hardware resources are more than enough/required.
The latency between Client and AOS is usually less than 1MS but sometimes it goes till 10-12 MS.
My concern is to continue this effort, is there any possibility that SQL 2017 can work with AX 2012 R3 CU12?? Otherwise, we cannot waste any more time, users are suffering.
And if this cannot work, we need to move back to SQL 2016 and copy 3 weeks of data from 2017 to 2016. The 2nd concern is that how to do this movement? as simple bak files do not work in this case. Maybe import data wizard of SQL studio can help?
Officially SQL 2017 is not supported, so there is a big risk, like you are facing now. Usually, a compatibility mode on the database would work but is not a guarantee.
Probably it is more secure (and supported) to go back to SQL 2016. I'm not a SQL administrator, so can't answer what exactly to do.
Business Applications communities