top of page
Writer's pictureKarl Donaubauer

"SQL Server" ODBC Driver Slow in Monthly Channel (Fixed)

Updated: Feb 28



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.

869 views7 comments

7 Comments


Kent Gorrell
Feb 26

tdf.RefreshLink

Error: 3283 Primary key already exists.

Version: 2312 Build: 17126.20190.

resolved by rolling back to 2311


Like

Kent Gorrell
Feb 25

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…


Like
Replying to

The build number means that the client is in the Monthly Enterprise Channel. There are several reports about error 3283 in that update channel. We are currently trying to clarify details of the problem with Microsoft and will inform you soon about the outcome here or in a new AFo article.

Edited
Like

Kent Gorrell
Feb 24

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…


Like

Heinrich Moser
Heinrich Moser
Feb 23

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!

Like

Heinrich Moser
Heinrich Moser
Feb 21

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).

Like
Replying to

We discussed about mentioning a channel switch as another potential workaround. At first I decided against it as I didn't see much benefit, but your post now "triggered" the third workaround. Thanks!

Like
bottom of page