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:
[HKEYLOCALMACHINE\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

• make it possible to select a subset of fields from a Salesforce object

Primarily, this would make it possible to work with SF objects that have exceeded the limit of 256 or whatever it is for Access. There would be other benefits too. But this alone would make the Salesforce/Access integration much more doable (right now I have to use an intermediary such as power query or sql server for these larger objects)

• make it possible to link to Salesforce reports. (less important but very helpful)

1 is really very necessary. I'd go so far as to say that without that the feature is only half baked, and not particularly useful.

I frequently run up against the 2048 handle limit (and from the online searching for how to resolve this, it's clear that I'm not alone). PLEASE INCREASE the number of object handles available to Access.
I'm supporting a reporting database that links to poorly designed tables (survey data in hundreds of fields that should be stored as records) in a vendor database that I have no control over. To make the data usable, I'm having to restructure the data, appending multiple union queries in order to get the data into a vertical format needed for our reporting needs. If I could modify the source system, I wouldn't have this problem, but many of us are supporting systems and databases that someone else created or has control over.

I wrote this code snippet (you may have to adjust it to match the tables in your database), and within a minute the whole program worked again. Hope this helps someone else, too:

Public Sub RenameAllTables()

Dim dbs As Database

Dim tdf As TableDef

Set dbs = CurrentDb

For Each tdf In dbs.TableDefs

    If InStr(1, tdf.Name, "tbl_") > 0 Then ' this way we don't change system tables

        tdfName = tdf.Name

        tdfNewName = Replace(tdfName, tdfName, "dbo_" & tdf.Name)

        DoCmd.Rename tdfNewName, acTable, tdfName


        strSQL = "SELECT * FROM " & tdfNewName

        Set qdf = CurrentDb.CreateQueryDef(tdfName, strSQL)

    End If

Next

End Sub
This uses the workaround suggested by Microsoft - to update a query instead of updating a table.

The code will rename tblCustomers to dbotblCustomers, then create a query: SELECT * FROM dbotblCustomers. The query is named tblCustomers

Now anytime your code runs an update to tbl_Customers, it will be updating the query (that selects from the table)!!

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.