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.
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.
Thanks for this information! I did encounter this error but I had no clue it was a bad patch in Access. Cheers! 😀
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
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?
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.