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

We are a small firm. We do not use client ID's for anything. You should have a feature, or box to check, for small firms that don't use IDs to check so that we do not see them on any reports that print. It looks terrible to see a client ID that was created for a client on a report that will never ever be used. You should have the box on the Primary Contact screen to suppress IDs when creating new clients OR a box when running due date reports to run to mark x to not see/use the client ID.

Opening/using forms that contain ActiveX controls, notably "Microsoft TreeView Control, version 6.0" cause Access to crash since at least version 16.0.11727.20210 on the Monthly channel. No versions in the Semi-annual (Targeted) channel seem to have this bug (yet).

The forms affected usually crash within moments of opening, but occasionally will work to some degree for several seconds.

Faulting application name: MSACCESS.EXE, version: 16.0.11727.20210, time stamp: 0x5d0d79e6
Faulting module name: ntdll.dll, version: 10.0.18362.1, time stamp: 0x9bbcb4a9
Exception code: 0xc0000374
Fault offset: 0x000df8cd
Faulting process ID: 0x50d4
Faulting application start time: 0x01d52cbe9164d25e
Faulting application path: C:\Program Files (x86)\Microsoft Office\Root\Office16\MSACCESS.EXE
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: c7ada4ee-be96-4c9d-ade3-47beaddc78d3
Faulting package full name:
Faulting package-relative application ID:

Versions we've tested that experience this bug:
16.0.11727.20188
16.0.11727.20210
16.0.11727.20224
16.0.11727.20230

Versions that work fine (so far):
16.0.11328.20318
16.0.11629.20246

We're using Group Policy to block the versions with this bug and instead installing 16.0.11629.20246

Computer Configuration > Administrative Policies > Microsoft Office 2016 > Updates > Prevent Office from being updated to a specific version
Enabled, blocked versions:
16.0.11727.20224:16.0.11629.20246|16.0.11727.20210:16.0.11629.20246|16.0.11727.20230:16.0.11629.20246

MS Access's ACE SQL engine continues to run with a variant form of ANSI-89 with some ANSI-92 features while the rest of the relational database world has adopted more recent ANSI standards and at the very least fully comply to the universal, lowest common denominator standard accepted in the industry: ANSI-1992.

Being a highly used, worldwide database for small to medium-sized shops and its popularity with the Office suite, enhancing Access's dialect to industry standards will add value to current and future users including the Microsoft brand. Even SQLite, a similar, very popular file-level database as open-source counterpart to Access, has a richer, more expressive updated SQL dialect.

Such specific features that would greatly enhance the expressiveness, portability, and efficiency of Access queries would include:

ANSI-1992

- Support of other joins - FULL OUTER JOIN, NATURAL JOIN, and CROSS JOIN; with use of USING clause;
- Support of CASE statements as more enhanced, portable version than IIF() especially for nested logic;
- Support of distinct aggregate functions: COUNT (DISTINCT ...), AVG (DISTINCT ...), SUM (DISTINCT ...);
- Support of wildcards operator, %, in GUI rather than * or use of ALIKE or restricted to ODBC/OLEDB queries;
- Support of CAST for data type changes as opposed to the non-portable C-functions: CStr, CDbl, CLong, CDate, etc.;
- Support of COALESCE for handling of NULL across columns as opposed to nested IIF(..IS NULL) or NZ();
- Elimination of the parentheses requirements for more than one JOIN which often frustrate many new users and require the use of Access GUI's Design View to build complex queries;
- Support of ON clause conditions on single table fields rather than joining tables first and then running WHERE.

Other ANSI

- ANSI-1999: Common Table Expressions (CTE) using WITH clause for more readable, maintainable, and less repetitive SQL code than subqueries and derived tables (supported in SQLite as of version 3.8.3, released 2014-02-03);
- ANSI-2003: Window functions using OVER and PARTITION BY clauses to supplant the domain (DSum, DMax, DCount, etc.) functions with more efficiency than correlated subqueries (supported in SQLite as of version 3.25, released 2018-09-15);
- ANSI-2003: Support for MERGE statement for synchronous UPDATE and INSERT needs based on conditional logic.

Other recommendations

- Support of EXPLAIN <QUERY> to allow users evaluate query operations especially use of indexes;
- Support of CREATE DATABASE as opposed to requiring code for creating .mdb/.accdb files;
- Support of CREATE TABLE AS instead of only SELECT * INTO for clarity of DDL action;
- Support of CREATE VIEW AS instead of requiring code with QueryDefs for creating stored queries;
- Distribute the ACE engine (.dll) as a shared object (.so) with CLI (similar to SQLite) for Unix (Mac, Linux) users (e.g., SQL Server 2016/2017 is now supported on Linux).

With backwards compatibility, above changes is a challenge but such features can be integrated with newer versions of the ACE engine (.dll) to be distributed to users, or with add-on patches, or entirely new Access version.

Additionally, though Microsoft strategically intends to keep SQL Server as its flagship database system and upgrading Access may somewhat interfere with this objective, arguably Access can be situated as a complement and not substitute to the enterprise server RDBMS. Rather than advancing Access’ front end GUI features for use as a complement to Excel, consider strengthening MS Access as a standalone, small-scale database engine product.