We are well aware of this issue and are working with the Windows team on resolving the problem.
It looks like the development team aren't in much of a hurry with this (or have sorted it and not told us). This has been waiting for a whole year now.
How are you getting on 4 months into this, please?
64 votes5 comments · Access (Desktop Application) » External Data Connectivity · Flag idea as inappropriate… · Admin →
We are well aware of this issue and are working closely with the Windows team on resolving it.
How are you getting on working closely with the Windows team on resolving this issue which came up in October 2018, please?
A new data connector that allows users to link to and import from Graph API is on our roadmap and will be released to O365 customers in the next few months.
"Link to and import from" would be read-only?
Remember you can also have subdatasheets to your datasheets as well. You can't have headers and stuff to the datasheet, but you could put the datasheet on a top-level form so you have the datasheet as your subform and then the subdatasheet runs off that.
3 votes2 comments · Access (Desktop Application) » External Data Connectivity · Flag idea as inappropriate… · Admin →
So, if an IT department switches on MFA, how do I continue to use Access to connect to the Azure SQL database, please? Have I missed something obvious?
4 votes2 comments · Access (Desktop Application) » Automating Tasks · Flag idea as inappropriate… · Admin →
And it doesn't always work well. Sometimes something goes wrong and no-one notices until they notice loads of files in the same folder as the original Access database named Database1.accdb, Database2.accdb, Database3.accdb or something similar.
I would suggest you don't save the password. It is better to run a connection to the back end when you start up your app, e.g. by using OpenDatabase (with an Access back end) or a SQL pass through query (if an ODBC back end). This creates a cache which is then automatically used by linked tables so they will then connect.
Bullzip is good for this for doing it programmatically.
Is there a situation where just unhiding existing controls is not as useful?
PS Such "roll your own" progress bars are likely to be more flexible and adaptable than anything Microsoft might put into a built-in one.
There are a number of ways to create a progress bar. Searching on "access progress bar" gives access to some of them.
As in over and above the use of the Anchor property?
I would vote for this, but have no votes left.
I agree. Access is different to the other Office programs. When I create a database with no access to the design stuff, e.g. Navigation Pane, design view for forms and reports, etc., I don't want "tell me what you want to do" stuck on my ribbon. It has no relevance to my database. It might as well have an advert for Siberian hamsters there.
Clippy 2 or what?
Sorry, there are 6 CommandBars in Access 2016 with no Name other than " ".
As well as the problem with the borders of windows, Access has other problems with high resolution screens.
When text size is set in Windows (10?) to more than 100%, the following happen:
1) The Navigation Pane updates slowly and jerkily when scrolling down it (even on my super whizzy PC).
2) The horizontal scrollbar at the bottom of a form obliterates the right half of the Search box next to it when the size of the Access window is reduced to a size which causes the horizontal scroll bar to appear.
Please note that if you want to check this out by altering your Windows text size, you will need to log off and log in again to see the change.
I've already used up my votes, so I can't vote for this as well. I have just bought a high resolution screen and the Navigation Pane text is now tiny with large vertical gaps between each line. It's a mess.
That's all part of vbWatchdog and, no, I have no connection with them apart from using their product(s).