top of page

Missing Semicolon in ODBC Connect (Fixed)

Updated: Jan 11

Description

There are several reports of a new bug when relinking ODBC tables in version 2312 Build 17126.20126 released to the Current Channel on January 4, 2024. For example, see these threads:


The bug causes the Connect property of the TableDef object of a linked ODBC table to return a value different from the actual connection string. The semicolon after the “ODBC” prefix of the connection string is missing.

Also, the RefreshLink method of the TableDef object appears to use a similarly incorrect connection string and thus fails to refresh the definition of the table. Examples:


ODBC;DRIVER=ODBC Driver 17 for SQL Server;SERVER=XXX;...

becomes

ODBCDRIVER=ODBC Driver 17 for SQL Server;SERVER=XXX;...


If you use a DSN:

ODBC;DSN=DsnName;...

becomes

ODBCDSN=DsnName;...


Creating new linked ODBC tables with either …

DoCmd.TransferDatabase acLink, "ODBC Database","ODBC;DSN=DsnName;...

… or …

Set td = db.CreateTableDef()
td.Connect = "ODBC;DSN=DsnName...

is not affected by the bug and still works as expected. This also applies to DSNless connection strings including the DRIVER keyword directly.


Cause

It looks like a regression in version 2312. The latest builds on the Insider channels also appear to be affected.


Status

The bug was first reported to Microsoft on the same day version 2312 was released. The Access team responded immediately that they are working on a fix.


Build 17126.20132 released to the Current channel on January 9 fixes this bug.


Note: This new build initially created performance/delay issues when using the old SQL Server ODBC driver. This problem should now be resolved. There is no new build. It should be enough to restart Access for the performance problems to disappear.


Until you get the semicolon fix, there are 2 potential workarounds:


Workaround 1

If you use ODBC links (DSN or DSN-less) try not to install version 2312 until the fix is released or roll back to version 2311 if you have already done so.


Workaround 2

Modify code that depends on the Connect property value to reset the missing semicolon, for example:

Replace(CurrentDb.TableDefs("TableName").Connect, _
							"ODBCDRIVER=", "ODBC;DRIVER=")

As the first parameter after the "ODBC" prefix can differ, check which one it is in your specific Connect property string and adapt the replacement construct to your requirements.

1,811 views18 comments

Recent Posts

See All

18 commentaires


Kent Gorrell
19 févr.

February 19. Just had clients encounter this issue on machines that were inadvertently updated to 2312.

Workaround: relink to SQL Server on a machine still on 2311 in the production environment, disable the relinking and distribute to machines on 2312.

In this application, once the links are established to the production db there is no further need to mess with tdf connect strings.

J'aime
Kent Gorrell
25 févr.
En réponse à

.RefreshLink

Error: 3283 Primary key already exists.

Version: 3212 Build: 17126.20190

Using: ODBC Driver 17 for SQL Server or SQL Server Native Client 11.0 So may not be relevant)

J'aime

Joris Tielkes
11 janv.

Thanks for this information! I did encounter this error but I had no clue it was a bad patch in Access. Cheers! 😀

J'aime

Oriel Tzvi Shaer
Oriel Tzvi Shaer
11 janv.

Workaround 2 didn't work for us. after

CurrentDb.TableDefs.Refresh

all connection strings returned to be wrong.

Also tried to check: File > Current Database > Caching Web Service and SharePoint tables > Clear Cache on Close

nevertheless, when getting refreshed all connection strings return to be corrupt

J'aime
Oriel Tzvi Shaer
Oriel Tzvi Shaer
11 janv.
En réponse à

Thank-you! Now after we indeed updated to the latest fix - and the problem is no longer there. Right you are!

J'aime

Heinrich Moser
Heinrich Moser
10 janv.

We have also received customer reports about the new performance issue with the old SQL Server driver introduced in the Jan 9 update.


Since the non-current channels also got updates yesterday: Is it known yet whether this issue only occurs on the Current Channel, or are the Enterprise Channels affected as well?

J'aime
Scott Kirk
Scott Kirk
10 janv.
En réponse à

Thanks Karl. Let me know if they need an example.

J'aime

Scott Kirk
Scott Kirk
09 janv.

Hello, we have received complaints from customers today of the programs not opening or taking minutes to open. I have confirmed they are running 20132. I was running fine on my build and tested by updating to the latest and I am experiencing the same issue. Normally takes 5-10 seconds to open and it's taking 2 minutes to open. We rolled one customer back to the prior version and they are back to normal. This is O365 linked to Sql Server. Please pass this along to MS or let me know if you have any questions/comments.

J'aime
Scott Kirk
Scott Kirk
10 janv.
En réponse à

Thanks....the work around isn't a good solution for us as it would require updating every clients odbc driver. We're up to about 50 workstations with the issue. Please keep us posted.

J'aime
bottom of page