I have a need to place a fairly complex chart in an Access report, and I wasn't able to create the chart in Access so I did it with Excel. The data actually resides in SQL Server, and there is a data connection that runs a stored procedure to bring it into Excel. This works find if you manually refresh the data in Excel, get the chart to refresh in Excel (which doesn't seem to work as easily as it should), and save the spreadsheet. If you then run the report the linked chart will work correctly. But when you are working with a database, a more typical scenario would be that you need to repeat the chart with different data for each group header or footer, so you may need to produce hundreds of them, and that has been a nightmare for me. I have been unable to discover a good method of automating the refreshing of both the data and the chart, and getting it from Excel to the Access report. Doesn't seem like this should be so difficult. For that matter, it would seem to make sense for charting to be the same in Access and Excel.

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.

Sizeable MDI forms in Access 2016 have a single-pixel border that is very hard to grab with the mouse.

The form borders show as a single-pixel whether the form mode is "no border", "dialog", "sizable" or "thin".

One work-around is to make the form a popup form, but if you make every single form in the database popup, you lose the MDI functionality and the ability to have a genuine popup form. When everything is on top then effectively nothing is.

This creates a serious accessibility issue particularly when combined with the fact that MS Access forms and controls don't resize correctly when the Windows text size/DPI is altered.

After update to Office 365 ProPlus 1808, a my customer start complaining about very unresponsive form in an application they have been using for many years.
I have been testing and checking for several days (with SQL Profiler, Wireshark packet sniffer and ProcMon), and seems the problem is reading %userprofile%\appdata\Local\Temp\JET8F62.tmp, which MSACCESS.EXE is doing a ReadFile Operation to. When the applications start to get unresponsive, many thousand reads are done to the same temp file. I have tried to change ODBC Driver (ordinary SQL Server v10, ODBC Driver 17 for SQL Server, V2017.172), I have tried to convert the .MDB file format to .ACCDB, I have tried to upgrade MSAccess 365 from 1808 to 1903. Also tried to run MSAccess as Administrator (in case of weird security settings) but no luck. Still same problem...
After about 30 minutes of usage, ProcMon shows about 600.000 events from MSACCESS.EXE, most of them ReadFile operations to the temp file. Each time the app get unresponsive, ReadFile operations events are starting to occur in ProcMon (several hundred per second). After ca 10-15 seconds, the ReadFile operations stopp occurring, and the app seams normal for a couple of seconds, but if the user move to another record in the form, the problem starts again... Also, when MSAccess is unresponsive, the MSAccess menu turns completely white (all icons etc disappear), and title of MSAccess Window shows "Not responding"...

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.