Description
In version 2312 build 17126.20190 you may experience a significant performance degradation with the classic "SQL Server" ODBC driver that comes with Windows. All types of operations with the driver may be slow and delayed. The affected build was rolled out to the Monthly Enterprise Channel starting on February 13, 2024.
There is a detailed bug report in this TechCommunity forum discussion.
Cause
Regression.
Status
Microsoft fixed the problem remotely on February 22/23 (depending on where you are in the world), two days after it was reported. There is no new build. Affected users just need to restart Access to restore normal performance with the "SQL Server" driver.
Just in case something goes wrong with your updates or the fix, we'll leave the previous workarounds here:
Workaround 1
If you are in the Monthly Enterprise Channel then try not to install version 2312 build 17126.20190 or roll back to an older build like 17029.20178 if you have already done so.
Workaround 2
You could (possibly only temporarily) change the update channel. Either to the slower Semi Annual, where the problem does not yet exist, or to the Current Channel, where the problem has already been fixed. See also the comment by Heinrich Moser below.
Workaround 3
Use a more modern driver like ODBC driver 17 or 18 for SQL Server.
tdf.RefreshLink
Error: 3283 Primary key already exists.
Version: 2312 Build: 17126.20190.
resolved by rolling back to 2311
Took 4 attempts to post on Microsoft Community and my post is now under review.
So here I am again.
Another client reported issues today.
I was able to RDP to a VM in their network
the error on
.RefreshLink
3283 Primary key already exists.
Version: 3212 Build: 17126.20190
Using: ODBC Driver 17 for SQL Server
the other client was using SQL Server Native Client 11.0
So I'm guessing it's not driver specific.
I can't just issue a new FE version of my application with a work around because the problem occurs in the code that checks for a new FE version
Their admin is doing a rollback to 2311 tomorrow morning.
And I'll ensure that they do have Automatic…
Fixing an issue without releasing a new build is total donkey dung.
How are we supposed to know if a particular machine is affected if we can't tell by the build number? Do we really need to waste hours testing every machine? or worse wait for users to complain and that often doesn't happen because they don't understand how "it" just stopped working without installing an update to the application.
If I seem a little peaved, it is because of the hours wasted on Monday when some, but not all, users were hit by the missing semi colon in connect string issue when some machines were updated to 2312. An issue that was supposed to have been fixed yet apparently…
I can confirm that, as of today, we can no longer reproduce the issue with the Monthly Enterprise Channel (same version, problem gone). Thank you!
Workaround 1 (downgrading) comes with the caveat that 17126.20190 includes some important security fixes (including a few Remote Code Execution vulnerabilities in Outlook). Thus, we currently recommend our customers to temporarily switch to the Semi-Annual Enterprise Channel (or the Current Channel, if they need some recently introduced feature).