#MSDynGP SQL Server 2025 Performance Issues with Microsoft Dynamics GP
This is repost of an article I wrote for the Knights of GP Blog. It explains the performance issues with using Microsoft SQL Server 2025 with Microsoft Dynamics GP and how to resolve them.
Here is the link to the original article on the Knights of GP site:
A summary of the performance issues with SQL Authentication.
Introduction
Microsoft released SQL Server 2025 in November 2025 and the System Requirements for Microsoft Dynamics GP web page shows that support for SQL Server 2025 was added for Dynamics GP 18.8 (Version 18.8.1941 January 2026 Hotfix) or later.
The upcoming release of Microsoft Dynamics GP 18.9, due in October 2026, will also support SQL Server 2025. You can use SQL Server 2025 with older versions of Dynamics GP, but that is not officially supported or tested.
Password Security Enhancement
One of the new enhancements of SQL Server 2025 was the addition of iterated and salted password verifiers based on PBKDF2 (Password-Based Key Derivation Function 2). This replaces the legacy SHA‑1–based verifier with a modern, hardened hashing algorithm designed to resist brute‑force attacks. PBKDF2 is intentionally computationally expensive as it iterates SHA-512 hashing 100,000 times. This slows down brute force attacks but also increases the CPU cost of each password verification.
Note: This enhancement is only used for SQL Authentication and not with Windows Authentication, which most modern applications use.
How this affects Microsoft Dynamics GP
Microsoft Dynamics GP uses SQL Authentication, which by itself would not be an issue, but it is also very common for developers to open and close additional connections to SQL on demand, when they need to execute SQL commands directly from Dexterity or other development environments.
Historically, the opening and closing SQL connections on demand had almost no overhead and so is used both in core Dynamics, Microsoft owned addon products, ISV (Independent Software Vendor) products and customizations written in Visual Studio Tools, Dexterity and even the discontinued Visual Basic for Applications (VBA).
Now that opening each of those additional connections is intentionally slowed down this can have a negative impact on the performance of Microsoft Dynamics GP, or any other product using SQL Authentication that opens and closes connections on demand.
Is there a coding solution?
While it is possible to change code to reuse connections rather than opening and closing connections, there is an issue which makes it much more complicated than you would expect.
Microsoft Dynamics GP is a single threaded application at the windows level, but internally it actually behaves as though it runs on two threads. It has a foreground thread which runs after a user has initiated an action and the user must wait for the foreground code to complete before control is returned to the user interface. It also has a background thread which runs queued processes while the application is idle (nothing running in the foreground). This causes an issue because the two threads cannot use the same SQL connection, otherwise they would interfere with each other.
For example, if a background thread issues a USE command to change database, then a foreground thread used the same connection and changed to a different database, when the background thread continued its execution, the current database would be incorrect.
As long as you can be sure that a particular script will always be executed in the foreground or background, you can re-use SQL connections. There are already objects in Dynamics GP which can be used to handle this. However, if you have scripts that run in the foreground or the background, they need to open a new connection to ensure they do not interfere with existing connections.
A final comment is that making changes to existing code that has been tested and is reliable, can introduce issues and becomes expensive to implement and test.
What is the solution?
The best solution that has been found is to use a global Trace Flag setting to disable this Security Enhancement and restore the previous SQL Server 2019 behaviour for SQL Authenticated connections.
For detailed information on the troubleshooting steps to find this issue and the steps to implement the Trace Flag solution please see the following article:
After implementing the Trace Flag setting to change the default behaviour for SQL Authentication password verification, you will need to change the passwords for all users for the change to actually take effect. This process is very simple if you use the SQL Login Maintenance window in GP Power Tools.
Conclusion
You can use Microsoft SQL Server 2025 with supported versions of Microsoft Dynamics GP, but to maintain the same level of performance as previous versions of SQL Server, you will need to implement the Trace Flag fix discussed above. If you implement this change immediately after installation you won’t need to reset passwords.
About the Author
David Musgrave has contributed to the Great Plains Dynamics and Microsoft Dynamics GP community for over three decades, with experience as a partner, an ISV and a Microsoft employee (14 years). He has developed many products and features both within core Dynamics GP and as addon products. He has received recognition as a Microsoft MVP (11 years), a GPUG All Star and a Dynamics Communities Summit Legend. As Managing Director of Winthrop Development Consultants in Perth, Australia – a Dynamics GP only ISV – he remains committed to supporting his products and the wider GP community. Check out the WinthropDC.com website and blog to stay up to date.
Hope you found this article helpful.
David
This article was originally posted on https://www.winthropdc.com/blog.