When scrolling in the navigation pane of Access 2016 on a Windows 10 box, the list always 'jumps" back up to a higher place than I have scrolled to. Though I have applied a few changes to my mouse and set screen enlargement to 100% (which is not realistic for me as the font is too small), the screen still jumps. I never had an issue in previous versions of Access. From researching a fix, It appears to be a long standing and unaddressed issue. It's a migraine trigger when the screen jumps and I'm trying to find something in long list of items. Please, fix this issue. Thank you.

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, MS_BoundColumn, MS_ColumnCount, MS_ColumnHeads, MS_ColumnWidths, MS_DecimalPlaces, MS_DefaultView, MS_DisplayControl, MS_Filter, MS_Format, MS_IMEMode, MS_IMESentMode, MS_InputMask, MS_LimitToList, MS_ListRows, MS_ListWidth, MS_OrderByOn, MS_Orientation, MS_RowSource, MS_RowSourceType, Name, OrderByOnLoad, OrdinalPosition, RecordCount, Required, ShowDatePicker, ShowOnlyRowSourceValues, Size, SourceField, SourceTable, TextAlign, TextFormat, TotalsRow, Type, UnicodeCompression, ValidationRule, ValidationText

ULS was a pain and way too many people implemented it incorrectly but it did serve a function which we have lost. People who develop Access apps for others need a way to completely lock down the FE. The .accde doesn't cut it because users can still modify tables, queries, and macros. We need something that acts like the .accdr but which isn't a trick. I understand why creating an .exe is not an option but you should be able to create a "permanent" format that acts like .accdr but which can't be undone by simply renaming the file. That would actually encourage developers to create more shrink-wrapped apps that are sold to the public if they can be assured that their intellectual property is protected.

Given that the trend is toward ODBC and away from OLEDB (ADO), there are number of gaps still present in Access as an ODBC client:

1) support for asynchronous operations
2) support for processing multiple resultsets
3) support for streaming large results
4) support for updating complex data sources (e.g. binding to a stored procedure and then specifying which stored procedure to call to perform insert/update/delete)

and other features that has been added to ODBC (currently at v3.8) but is not available via DAO.

This is necessary to enable Access to transition away from ADPs, better leverage remote data sources and handle more complex structure than just tables and views. Note that in past, Access had ODBCDirect feature which was massively underutilized due to the fact that it was simply not useful with Access forms/reports; and was a code-only solution. A successful solution should be 100% compatible with Access forms & reports.

Given the fact a decision on AWA has been taken, here's I think what the development team should do. 1. Make AWA datamacros available in Access Desktop 2. Extend with support of Update/Create/Delete Queries in the query designer. 3. Explode functionality by making datamacros that return just one value available as functions within expression builders of queries and datamaros 4. Support the database qualifier in front of tablenames the way it is already available in SQL-Server between databases. this way users can integrate AWA managed and non-AWA managed very easily. (integration with CLR SQL-server projects and other tools that generate Stored Procedures (LinqToSQL). This way all SP_ functionality in SQL-server (which spans as much as Powershell does (encryption, certificates, you name it and it's there) can be made available to Access Projects. 5. Provide for a proper connector to PowerApps/Flow that is aware of AWA managed databases (and their connectivity with each other and unmanaged databases.