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

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

Easily recover lost and permanently deleted data with the help of EDB to PST Converter application that is designed by using the rich algorithm and the best technology. It helps the user to convert the required folders from priv 1.edb file and pub 1.edb file included with the email, notes, tasks, attachments, contact, draft, inbox and calendar (For, CC, From, Date, Time, Subject, Object, and Cc). It not only recovers data but also converts into new PST file format included with all properties of email like To, Cc, From, Date, Time, Subject, Object, and Bcc. Using it the user can easily export those file which they want to convert from EDB data file to PST file format without any hassle. It is compatible to export one as well as more than one file into PST, EML, EMLX, MSG, vCal, vCard, and MBOX file format with 100% accurate result. With the assistance of this application you can migrate the data of EDB file into Office365 & Live Exchange Server. It provide an accurate result that is better than your expectations. It provide free demo version that allows to migrate 30 emails per folder without any hassle. You can also return it under 30 emails if you have any issue with this application. This is the number one tool for the conversion work.

Read More: https://www.inquitsoftware.com/en/pages/edb-to-pst-converter.html

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 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!