Optima slow after the SQL Server 2025 upgrade? Cause and fix

For one of our clients, posting documents in Comarch ERP Optima slowed down after SQL Server was upgraded from 2022 to 2025. Optima itself was already on the latest version (2026.5), so only the database server changed. The Windows Server 2019 machine hosts several hundred company databases, and staff use Optima mostly over remote desktop.

Symptoms

Posting each document took 4 seconds, whatever its type: purchase invoice, sales invoice or a KSeF document. A batch of documents took about 49 seconds. Staff reported that operations which used to take seconds now took minutes.

(opens the full-size image)

What we checked and ruled out

Before finding the cause, we measured the server during working hours. These parts worked normally:

• Disk: data reads about 0.2 ms, transaction log writes 3–4 ms.
• CPU: SQL Server used on average less than one of eight cores.
• Locks: none in measurements taken every second.
• Network on the server side: waits of about 1 ms.
• Antivirus: Microsoft Defender exclusions for SQL Server changed nothing.

The cause: slower password checks in SQL Server 2025

SQL Server 2025 stores and verifies SQL login passwords with PBKDF2 (100,000 iterations of SHA-512). Microsoft lists this change among the known issues of SQL Server 2025 because it slows down logins. The server rewrites old password hashes to the new format on the first successful login after the upgrade.

In our measurements, a new connection with a SQL login took 118.8 ms on average, and with a Windows account 2.4 ms.

With a single connection, 120 ms would not matter. Optima connects with the SQL login CDNOperator and opens a great many new connections: one posting batch made about 166 new connections in 49 seconds, and 15 minutes of normal office work made 2,481 logins. For each of them, the server now checks the password the new, slower way.

We estimate that in a 49-second batch, logins alone took 12–20 seconds. The rest is database queries and the program's own work. Logins account for a large part of the delay, but not all of it.

How to check whether this is your case

One query in SQL Server Management Studio is enough:

SELECT name, CONVERT(varchar(6), password_hash, 1) AS hash_type
FROM sys.sql_logins;

0x0300 means the new PBKDF2 format, and 0x0200 the old, fast format from SQL Server 2022.

What helped: trace flag 4671

This fix is experimental. Trace flag 4671 is not in Microsoft's documentation, Microsoft does not support it, and some SQL specialists advise against it. It worked for our client. We did it in this order:

1. A full backup of all databases, including the system database master, which holds logins and passwords. Many simple backup scripts skip system databases.
2. A copy of the current password_hash of the CDNOperator login, so the old password can be restored.
3. A test of the flag on a temporary test login, after working hours.
4. Turning the flag on with DBCC TRACEON(4671, -1) and the -T4671 startup parameter in SQL Server Configuration Manager, so it survives a restart.
5. A new CDNOperator password set in Optima while the flag was on (Tools, Database server, Change password of user “CDNOperator”), with “Save the password for all Windows users” ticked. Optima has to run as administrator, otherwise the shared password file is not updated.
6. The new password entered on every computer with its own Optima installation, in the Automatic Operations Service and in every program that uses this login.

Results on the test login (10 attempts per step):

• Without the flag: 118.8 ms per new connection.
• Flag on, password still in PBKDF2 format: 116.8 ms. A login alone does not change the format.
• Flag on and the same password set again: 0.8 ms.
• Flag off: 121.1 ms. The first login rewrote the hash back to PBKDF2.

(opens the full-size image)

(opens the full-size image)

Result

A new SQL login connection went from 118.8 ms to 0.8 ms. Posting one document now takes about 3 seconds instead of 4. That figure comes from a single test. Staff who connect to the server over remote desktop say Optima works much better. We have not yet compared the same batch of documents before and after the change on one computer.

What to watch out for

• The flag alone does nothing. The password has to be set again while the flag is on.
• We do not turn the flag off. Without it, SQL Server goes back to PBKDF2 on the first login: the program keeps working, but slowly again.
• After every SQL Server update we check the flag and the hash format. A future update may change how the flag works. After security update KB5126967 the flag still worked for us.
• Going back to SQL Server 2022 is not a simple way out: databases and backups from SQL Server 2025 cannot be restored on 2022.
• Programs still logging in with the old password show up in the SQL Server log (ERRORLOG, error 18456). For us, one was an old, unused web application on the server.
• The Automatic Operations Service in Optima 2026.5 does not run under LocalSystem. It needs its own Windows account, and the password file has to be in that account's profile.
• We do not give the CDNOperator password to people outside the company. This login usually has access to the databases of every company in Optima.
• For computers that connect to the database over VPN or Wi-Fi, network delay adds up on each of Optima's many connections. That is why we recommend working over remote desktop on the server.

Checking the flag after an update:

DBCC TRACESTATUS(4671);

Sources

• Microsoft: SQL Server 2025 known issues
• Microsoft: sys.sql_logins
• VladDBA: SQL Server 2025 PBKDF2
• Comarch: CDNOperator

We can do this for you

If Optima slowed down after a SQL Server upgrade, we will find the cause and make the change with a backup and a way back. More on how we look after IT for accounting firms. Write to kontakt@proop.pl or call +48 690 504 074.