• 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.

We have a webservice on which we have a PowerApp connector that enables PowerApps to run any macro, vba procedure/function, opening of a form to fill in text-fields and/or perform the equivalent to buttonclick-events in an Access Application. If MS-Access out of the box could configure and enable a webservice on the machine it's running and thus would enable a PowerApp to be a cloudfirst/mobilefirst frontend presentation layer, MS-Access 2019 would really become something new. When the Access application has linked SQL-tables to SQL-2016 or up, it can easily delegate the creation of JSON to SQL-server, but I wouldn't be surprised VBA already has JSON functionality in Access 2019.

When the Linked Table Manager sees a column name in a SQL Server table with 64 characters, it only uses the first 63 characters of that column name.

After linking, an attempt to view table data will fail, with the message

"ODBC--call failed"

"[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Invalid column name "'123456789012345678901234567890123456789012345678901234567890123'."

The column name in my table on SQL Server is:

"1234567890123456789012345678901234567890123456789012345678901234"

So Linked Table manager is truncating that for some reason.

There is a 64 character limit for object names.

I cannot find any documentation anywhere saying there is such a limit of 63 characters in ODBC linked tables.

Same issue with ODBC v17 (v17.3) as well as ODBC v13.

The version of SQL Server is SQL Server 2017, on Windows 10 Pro. The version of MS Access is from Office 365, (Access Version 1903), and is installed on the same Windows 10 Pro instance as the SQL Server is using. For the Linked Table manager, my results are the same whether using the Windows Integration authentication as the SQL Server (login) authentication.

I believe I have hit a new bug in ACCESS.
This conflict shows up when a front end using standard Access SQL connects to a Back-end using SQL Server Syntax (ANSI92).
It results in very strange behavior with Combo-Boxes failing to Auto-Complete and Wildcard Queries not returning results.
Access 2010 is immune! Phew.

It is repeatable and can be reproduced by following the process:
There appears to be a new bug in ACCESS 365 / Click to Run.
It DOES NOT EXHIBIT on Access 2010, but I have not tested with 2013.

Issue: Combo Boxes (drop-downs) fail to Auto-Complete List Items when user is keying Data.
Additionally, some Queries fail to return results.
The Cause:
SQL Server Syntax setting.
To Reproduce:
Create a New Database (Call It TestBE or Similar)
Go to File > Options > Object Designers
Under Query Design find “SQL Server Compatible Syntax (Ansi 92)”
Untick/ Uncheck if selected. Click OK to apply…
Create a new Table tblLinked with an ID (auto-number) field and a Description Field (Short Text)
Populate a few rows of this table with some words
Close the TestBE Database.

Create a new Blank database (Call it TestFE or similar) with Access 365CTR (I’m using Version 1905)
Go to File > Options > Object Designers
Under Query Design find “SQL Server Compatible Syntax (Ansi 92)”
Untick/ Uncheck if selected. Click OK to apply…
Create a small Table tblTEST with an ID (auto-number) field and a Description Field (Short Text)
Populate this table with some random words in the Description.
Create a new Unbound Form (Form1). Add a ComboBox with RowSource set to tblTEST. Set 2 Columns, with Column widths set to 0cm;5cm
Normal Behavior:
Open the form Form1. Type the first letter of a Description in the Combo box. Access will autocomplete the word if matched. Correctly.
The ISSUE:

Now still in the TestFE database; link to the table tblLinked in the TestBE Databases.
Open Form1 and test the Combo again. Functionality is still OK. Clear the Combobox.
Open the linked table tblLinked. It works fine. Close it.
Open Form1 and test the Combo again. Functionality is still OK. Clear the Combobox.
Create a new query on tblLinked. “SELECT * FROM tblLinked” Save this as qryFail.
Open Query qryFail in datasheet view. Looks fine.
Open Form1 and test the Combobox with a single letter . Autocomplete still works.
Clear the Combo box.
Open qryFail again and Click Refresh All from the Home Ribbon.
Now on Form1 test the ComboBox again. Auto-complete Fails!
It will stay failed until the database is closed and reopened.
Any Query’s in the Database using a wildCard Like * will now only return results if using SQL Syntax of Alike %.

In Access 2010 this is not seen!

As One Drive is Cloud based, I'd like questionnaire templates that I can then customize for my interests / requirements using either MS Excel or MS Access. Then once created, I'd like to be able to 1) Invite Specific Respondents to fill in the questionnaire via a link; and 2) Post the Survey on a separate website with the data being saved in my specified One Drive Folder. It would be great if the templates or template forms came with easy-to-use or paste items for building the questionnaire such as contact info, date formats, text formats number formats, logic formats, multiple choice formats, etc., such that the questionnaire is created. The questionnaire is designed from a table menu type list that is dragged from the table menu to the page, for which then the specific question written. The questions remain capable of being modified or their numeric reference changed until such time that the questionnaire - database is ready for use at which time the questionnaire - database is locked as is. Once locked, respondents can enter their data and the data can be exported or tabulated based on queuried interests or objectives, etc.

I believe I have hit a new bug in ACCESS.
This conflict shows up when a front end using standard Access SQL connects to a Back-end using SQL Server Syntax (ANSI92).
It results in very strange behavior with Combo-Boxes failing to Auto-Complete and Wildcard Queries not returning results.
Access 2010 is immune! Phew.

It is repeatable and can be reproduced by following the process:
There appears to be a new bug in ACCESS 365 / Click to Run.
It DOES NOT EXHIBIT on Access 2010, but I have not tested with 2013.

Issue: Combo Boxes (drop-downs) fail to Auto-Complete List Items when user is keying Data.
Additionally, some Queries fail to return results.
The Cause:
SQL Server Syntax setting.
To Reproduce:
Create a New Database (Call It TestBE or Similar)
Go to File > Options > Object Designers
Under Query Design find “SQL Server Compatible Syntax (Ansi 92)”
Untick/ Uncheck if selected. Click OK to apply…
Create a new Table tblLinked with an ID (auto-number) field and a Description Field (Short Text)
Populate a few rows of this table with some words
Close the TestBE Database.

Create a new Blank database (Call it TestFE or similar) with Access 365CTR (I’m using Version 1905)
Go to File > Options > Object Designers
Under Query Design find “SQL Server Compatible Syntax (Ansi 92)”
Untick/ Uncheck if selected. Click OK to apply…
Create a small Table tblTEST with an ID (auto-number) field and a Description Field (Short Text)
Populate this table with some random words in the Description.
Create a new Unbound Form (Form1). Add a ComboBox with RowSource set to tblTEST. Set 2 Columns, with Column widths set to 0cm;5cm
Normal Behavior:
Open the form Form1. Type the first letter of a Description in the Combo box. Access will autocomplete the word if matched. Correctly.
The ISSUE:

Now still in the TestFE database; link to the table tblLinked in the TestBE Databases.
Open Form1 and test the Combo again. Functionality is still OK. Clear the Combobox.
Open the linked table tblLinked. It works fine. Close it.
Open Form1 and test the Combo again. Functionality is still OK. Clear the Combobox.
Create a new query on tblLinked. “SELECT * FROM tblLinked” Save this as qryFail.
Open Query qryFail in datasheet view. Looks fine.
Open Form1 and test the Combobox with a single letter . Autocomplete still works.
Clear the Combo box.
Open qryFail again and Click Refresh All from the Home Ribbon.
Now on Form1 test the ComboBox again. Auto-complete Fails!
It will stay failed until the database is closed and reopened.
Any Query’s in the Database using a wildCard Like * will now only return results if using SQL Syntax of Alike %.

In Access 2010 this is not seen!

I still do thoroughly hope, you will integrate ETL-features to Access!
In EXCEL as well as in PowerBI you can use "retrieve and transform data" to collect data from diffent sources.
I don't want to write back data to the sources.
Many of my clients - financial controllers and data analysts - use ACCESS as a kind of datamart for their reporting, as I wrote in my BLOG "controllingexcellent". They collect data from different source, mostly TXT-files, CSV, Web, EXCEL-Files and Databases at the same time.
It is the "single source of truth" where data is stored. Many other reports in EXCEL or PowerBi receive data from this single source, where all data has the same relevance.
Here it is also possible to update just part of the data, without re-loading those parts loaded previously. Timestands help to control the topicality of the updates.

I don't see any competion between EXCEL an ACCESS, I think each should be used, for what it does best. ACCESS stores data.

I think it would be very nice if ODBC-Connections to a SQL-Server would preserve:
a) The Primary Key constraint while exporting.
b) Constraints like default values while exporting.
c) Extended properties like 'MS_Description' while exporting.
d) Auto value/IDENTITY while exporting.

And also b) + c) while importing or linking tables.
While a) + d) still works (sometimes) while importing or linking, it does not work in a one to one fashion.

The Microsoft SQL Server Migration Assistant for Access (32-Bit) is, unfortunately, buggy (or completely broken after v7.3.0) and extremely slow to open even medium-sized databases.

Once upon a time, this used to work fine. I still have old tables, that contain these extended attributes from the old Upsize Assistant:
AggregateType, AllowMultipleValues, AllowValueListEdits, AllowZeroLength, AppendOnly, Attributes, Collatinrder, ColumnHidden, ColumnOrder, ColumnWidth, DataUpdatable, DateCreated, DefaultValue, DisplayViewsOnSharePointSite, FilterOnLoad, GUID, HideNewField, LastUpdated, MSBoundColumn, MSColumnCount, MSColumnHeads, MSColumnWidths, MSDecimalPlaces, MSDefaultView, MSDisplayControl, MSFilter, MSFormat, MSIMEMode, MSIMESentMode, MSInputMask, MSLimitToList, MSListRows, MSListWidth, MSOrderByOn, MSOrientation, MSRowSource, MS_RowSourceType, Name, OrderByOnLoad, OrdinalPosition, RecordCount, Required, ShowDatePicker, ShowOnlyRowSourceValues, Size, SourceField, SourceTable, TextAlign, TextFormat, TotalsRow, Type, UnicodeCompression, ValidationRule, ValidationText