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.

Please fix the combo box RowSource datatype binding bug.

The bug is as follows:
1. Create a table [Table1] with two columns:
- [NumberField], datatype: Number, Double
- [TextField], datatype: Short Text

Add 1 Row to the table:
[NumberField] = 10
[TextField] = "Some Text 10"

2. Create a combo box:
- Set the RowSource of the combo box to this:
SELECT NumberField, TextField FROM Table1;

3. Add a Button to the form: [cmbErrorExample]
Add On Click Event:
If Me.cmbErrorExample.RowSource = "SELECT NumberField, TextField FROM Table1;" Then
Me.cmbErrorExample.RowSource = "SELECT TextField, NumberField FROM Table1;"
Me.cmbErrorExample.DefaultValue = "Some Text 10"
Me.cmbErrorExample.Value = "Some Text 10"
Else
Me.cmbErrorExample.RowSource = "SELECT NumberField, TextField FROM Table1;"
Me.cmbErrorExample.DefaultValue = 10
Me.cmbErrorExample.Value = 10
End If

Now open the form:
Drop the combo box, you should see the one row with values:
10 | Some Text 10
Select the row - the value of the field becomes 10.

Now, click the button. The Rowsource should change to:
"SELECT TextField, NumberField FROM Table1;"

However, if the user has already made a selection as instructed above, error appers:
---------------------------
Error Occurred in Sub cmdToggleRowSource_Click of Module Form_Form1
---------------------------
Error The value you entered isn't valid for this field.
---------------------------
OK
---------------------------

Expected: the code should be able to programmatically change the Rowsource of the combo box.

Actual: Because the unbound field has had a numeric value assigned as a value, the programmatic change of the RowSource of the combo box to a text value results in a type mismatch that should not be happening.

This used to be possible in Access 2003, but in Access 2019 the combo box appears to change itself to be bound to a numeric data type, even though it is an UNBOUND field.

This is a problem when creating forms that change combo box data sources programmatically.

This URL contains a .accdb with a sample form that demonstrates the issue:
https://1drv.ms/u/s!AhezOlimTLoah-V27m77K4MRlU5loQ

We can't see the language of keywords, ads or extensions from Editor as the column is not available at this level. The language is only displayed at the Campaign and Adgroup levels.

For accounts with just one language it is not problematic, but when campaigns and adgroups have multiple languages we can't dispatch the data we export for keywords, ads and extensions.

As NQS requires the data to be sent per market AND language, it is inconvenient when requesting for an editorial review.

Could it be possible to add the hereditated language to keywords, ads and extensions in Editor? Langage from adgroup first, if no language setup then from the campaign, otherwise from the account.

Thanks.

Every time I get an Office update, my Access Add-ins are uninstalled. This has been going on for at least a year. It doesn't affect all add-ins, about 1/4 of them stay (I have 26 installed). These may be ones that were installed with an .exe installer.

I think this is a bug but I don't think it will get a lot of attention because Access Add-ins aren't that popular. If you use add-ins and have seen this happen please vote.

My work around for this has been to use RegEdit to save my add-in registry settings to a .reg file. After I get an Office update, I open a File Explorer window as Administrator and then merge the .reg file. This will restore my add-ins without having to open Access as Administrator and Installing each one from the Add-ins Manager.

The registry path on my computer is:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access\Menu Add-Ins]

I am using Office 365 (16.0.10730.20264) 32-bit

The recent Access updates that broke the most simple update queries was bad. However, Microsoft's response was even worse. Rather than Microsoft fixing the very serious problem they created, they said we should change the way we update records in our applications. What moron thought that was an appropriate response? Like many other throughout the world, we have a production system with 400K lines of code and you want us to rewrite every update statement because you do not want to roll out a bug fix? Then, someone thought it was a good idea to wait 30 days to fix the problem. What are people to do in the meantime? These are production systems that people rely on every day to do their jobs! Again, what tone-deaf moron at Microsoft thought this was an acceptable response? Clearly someone needs to be fired.