Bug fix needed urgently!

11/12/19 Office ProPlus 365 Update broke Access UPDATE query with WHERE Clause.

Queries without WHERE clause still work.

Can be recreated in new mdb or accdb database with single table. Write a query that tries to Update a value in the table. If the query has a Where clause, the query fails with a message of:

Query 'qryName' is corrupt

The database is NOT corrupt. Moving the database to another machine that has not been updated with today's Update (16.0.11328.20468, depending on Channel type), allows the query to work.

Query fails whether table is in the local database or the table is linked.

"Microsoft Graph is the gateway to data and intelligence in Microsoft 365. Microsoft Graph provides a unified programmability model that you can use to take advantage of the tremendous amount of data in Office 365, Enterprise Mobility + Security, and Windows 10.
You can use the Microsoft Graph API to build apps for organizations and consumers that interact with the data of millions of users. With Microsoft Graph, you can connect to a wealth of resources, relationships, and intelligence, all through a single endpoint: https://graph.microsoft.com."

It seems that just about every language except VBA can be used to run this. Access is a database app and it would be great to be able to use it to collect data to feed into, say, Office 365 groups, users and so on.

Since 8/1/2018, MS Access has been crashing repeatedly on multiple machines in our office. We are on 64 bit Office 365 and Windows 10. It appears some bug must have been introduced during one of the automatic updates.

This crash appears to occur with automation where I think a second instance of MS Access is calling an MS access program, but not totally sure:

Faulting application name: MSACCESS.EXE, version: 16.0.10325.20118, time stamp: 0x5b64d927
Faulting module name: OLEAUT32.dll, version: 10.0.17134.48, time stamp: 0xebd737a3
Exception code: 0xc0000005
Fault offset: 0x000000000008a283
Faulting process id: 0x32a0
Faulting application start time: 0x01d43fb636a345d3
Faulting application path: C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE
Faulting module path: C:\WINDOWS\System32\OLEAUT32.dll
Report Id: b87fac84-eca0-480b-8855-0437a376d7e8
Faulting package full name:
Faulting package-relative application ID:

This crash occurred with conditional formatting in a continuous form

Faulting application name: MSACCESS.EXE, version: 16.0.10325.20082, time stamp: 0x5b524023
Faulting module name: ntdll.dll, version: 10.0.17134.165, time stamp: 0xf4df6dc2
Exception code: 0xc0000374
Fault offset: 0x00000000000f4d1b
Faulting process id: 0x2f34
Faulting application start time: 0x01d42cda8c32b6c7
Faulting application path: C:\Program Files\Microsoft Office\Root\Office16\MSACCESS.EXE
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: cd99d3ff-d7aa-4af6-9385-5db23f91f481
Faulting package full name:
Faulting package-relative application ID:

This crash occurs when we click in a combo box and that box is locked and enabled is set to false:

Faulting application name: MSACCESS.EXE, version: 16.0.10325.20118, time stamp: 0x5b64d927
Faulting module name: mso30win32client.dll, version: 0.0.0.0, time stamp: 0x5b5da093
Exception code: 0xc000041d
Fault offset: 0x000000000009b445
Faulting process id: 0x1178
Faulting application start time: 0x01d43fbb05c2f1a3
Faulting application path: C:\Program Files\Microsoft Office\Root\Office16\MSACCESS.EXE
Faulting module path: C:\Program Files\Common Files\Microsoft Shared\Office16\mso30win32client.dll
Report Id: 2d2299db-57cf-42f3-8ced-5cea27393b1b
Faulting package full name:
Faulting package-relative application ID:

Customer has a HRD application connects to Access DB. After installing ODBC 2016 or Office 2016 (which includes ODBC), the awards in Logbook ceases to work and reports only zeros. Customer has a workaround for now:

Fix: An automatic workaround will be put into HRD.
Workaround:
Modify the registry to use the new (old) strings.
1. Pull up regedit and go to HKCU\Software\ODBC\ODBC.INI\ODBC Data Sources
2. Note the “Microsoft Access Driver (*.mdb, *.accdb)”. That was added partially in 2007 and fully in 2010. Some older entries may have the old style string already.
3. Change them back to the original “Microsoft Access Driver (*.mdb)”
(Although this looks trivial, the poorly written ODBC driver requires an EXACT match.)
4. Restart HRD and it should work.
6) Customer clearly confirmed me that there is nothing to do with bitness of office, OS or drivers.

What we need from PG:
Is this an expected behavior or anything By Design? Please confirm.

I have a form with a navigation control. In a navigation button, I set the Navigation Target to the Report "rpt_Test". In the Open event of rpt_Test, I set a filter:

Private Sub Report_Open(Cancel As Integer)

Me.Filter = "TestID > 5"
Me.FilterOn = True

' Access crashes on the End Sub Statement in the second execution
End Sub

When I navigate to this button, the Report_Open event is fired twice, and the crash occurs on the Exit Sub the second time around. It is a hard crash with the message "Access has stopped working".
I can produce the crash as many times as I want, on different machines and on Access Versions 2013 and 2016. My Access 2016 version is 1710 (Build 8625.2132 Click-To-Run), i.e., the most recent version.

Known workaround: Instead of setting then Filter property, set the recordsource of the report:

Me.Recordsource = "Select * From & " Me!Recordsource & " Where TestID > 5"

This requires that the record source is a table or a stored query.

Matthias Kläy
Kläy Computing AG