Software from the device manufacturer installed on the
However, I received info from a contact of mine that this issue is fixed on Microsoft’s end and that a bug fix should become publicly available as new version 2206 on Thursday or Friday this week ( / 03) for the current (monthly) channel of Microsoft 365.Īs of 19:30 UTC this update was not yet available to me.That connects by USB to a Windows 10 Pro laptop. There is still no official info from Microsoft on this whole issue that I’m aware of.
However, as we’ve now seen a wide variety of ODBC drivers being affected by issue, it is very likely that applications using other DMBS, such as PostgreSQL, are also suffering from this bug. I have no installation of PostgreSQL available in my local development environment to try to reproduce the issue with that database server. Unfortunately, using this unaffected driver is not a workaround in most scenarios as you probably need Unicode support when you were using that ODBC driver. The MySQL ODBC 8.0 ANSI Driver seems not to be affected. I can reproduce the problem with a MySQL database using the MySQL ODBC 8.0 Unicode Driver. I’ve read a couple of public posts this week where people report that they are also affected by this bug using a MySQL or PostgreSQL backend database.Ī quick test appears to confirm the issue.
Installing a different driver and relinking the tables can be done without any changes to the code or design of an affected Access application.Īnother option to deal with this issue is to revert to a previous version of Microsoft Office 365. Relinking the SQL Server tables using the “ODBC Driver 17 for SQL Server”, or another non-affected ODBC driver is my recommendation to work around the issue. ODBC Driver 18 for SQL Server – Not tested, but most likely also not affected by this issue.ODBC Driver 17 for SQL Server – Not affected by this issue.ODBC Driver 13 for SQL Server – Not affected by this issue.ODBC Driver 11 for SQL Server – Not affected by this issue (I’ve got a report from someone claiming this driver is also affected, but it might be a mix-up with Native Client 11.).SQL Server Native Client 11.0 – Affected by this issue.SQL Server Native Client 10.0 – Affected by this issue.I did a quick test of the other ODBC drives for SQL Server I’ve got installed here. The problem does not happen when the table is linked into the Access database using the “ODBC Driver 17 for SQL Server” (I tested version 2017.176.01.01.). If you want to know more about using SQL Server Profiler, particularly when diagnosing issues with Microsoft Access client server application, I suggest you watch my video on the topic: Why (still) use SQL Server Profiler? Additional Info 2 / Workaround: Here is SQL Server Profiler trace, which shows that instead of the actual primary key values there are unrelated Unicode characters sent to the server:
(If you want to know more about how Access works with ODBC linked tables, check out my text Microsoft Access - ODBC Linked Tables – Mechanisms and Performance.) Snapshot recordset are not affected by this issue. If you do not need an updateable recordset from the linked table, you could create a query in Access creating a Snapshot type recordset. The latter part is what fails and results in “#Deleted” being displayed instead of the actual data. It first retrieves the primary key and then uses each pk value to fetch the remaining columns of each record. The problem is related to the way Microsoft Access queries the records in dynaset recordsets.
Observe: All columns in all records display #Deleted Additional Info 1: Open the linked table by double clicking the table in the Navigation Pane.Ĥ. See the list in the “Additional Info 2” section below.)ģ. (The issue is also reproducible with other ODBC drivers. Link the table into a Microsoft Access database using the “SQL Server” ODBC driver (I used version. INSERT INTO TestNVC (NVCPK, Dummy) VALUES ('ABC', 'Test 1') Ģ. NVCPK Nvarchar(100) NOT NULL PRIMARY KEY,