For MS Access textboxes on Forms that handle dates you can set the textbox to allow the user to optionally use a built-in DatePicker. However the DatePicker returns the date in a format set by the Windows system (e.g. as Set by Control Panel > Region > |Formats| > [Additional Settings ...] > |Date| > Short Date:)

If you use a unorthodox windows system date format, e.g. "yyyy-/MM-MMM/-dd, ddd" returning "2021/-05-May/-18, Wed" then this can be undesirably returned by the DatePicker.

Instead the DatePicker should return a date that honors any custom format set by in Format property of the Textbox control itself. E.g. If the developer sets an ISO8601 format "yyyy-mm-dd" in the Textbox format property then the DatePicker should return text like "2021-05-18".

For MS Access textboxes on Forms that handle dates you can set the textbox to allow the user to optionally use a built-in DatePicker. However the DatePicker returns the date in a format set by the Windows system (e.g. as Set by Control Panel > Region > |Formats| > [Additional Settings ...] > |Date| > Short Date:)

If you use a unorthodox windows system date format, e.g. "yyyy-/MM-MMM/-dd, ddd" returning "2021/-05-May/-18, Wed" then this can be undesirably returned by the DatePicker.

Instead the DatePicker should return a date that honors any custom format set by in Format property of the Textbox control itself. E.g. If the developer sets an ISO8601 format "yyyy-mm-dd" in the Textbox format property then the DatePicker should return text like "2021-05-18".

In order to add a Add-in (.mda) file into MS Access, the user has to be in the local admins group. Even if you are a domain admin, not having local admin rights won't work because your user profile changes when you open MS Access as Admin with other credentials.

Full Detail: In order to Install an Add-in library in MS Access 2016 (and at least the two prior versions) you have to open MS Access 'Run as Administrator', then do the install, then close and reopen as the standard user. If you are not in the local administrators group you must log off, login with admin rights, add the user into the local admins group, logout, login as user, run MS Access as Admin, install the add-in, remove the user from the local admins group, then logout and back in again to use it.

The simplest solution is to allow this whole process to be done by the regular user, as long as the appropriate settings are in the Trust Center. Could be anything; Add-in File in the Trusted Locations, Add-in File is a Trusted Document, Add-in File is Digitally Signed requirement stops install if not signed, but otherwise allow. I like the last one the best myself.

Use EdbMails for seamless migration of user mailboxes from PST files to Office 365. Thanks to its easy to use user interface, even a non-technical person can easily make use of the PST to Office 365 migration utility from EdbMails and perform the migration operation.
EdbMails will display all the mailboxes/ users from your Office 365 tenant during PST to Office 365 migration operation. You can map your PST mailbox to Office 365 user account easily and even apply include/exclude email filters.
Some of the salient features of EdbMails Import PST to Office 365 Migration tool include:
Truly secure Migration of all PST file data
Reliable Outlook PST to Office 365 migration
Incremental PST migration to ensure there are no duplicates
Brick level migration that allows you to migrate individual items of your choice from mailbox/folders
Capable of recovering unintentionally deleted items
No Outlook dependency

Visit: https://www.edbmails.com/pages/pst-migration-tool.html

We have a number of users at work who regularly report, when using Access 2016, that they get a "System Resource Exceeded" error when running certain queries. It is intermittent, but happens frequently. Didn't used to happen on Office 2010, or under Windows 7. Happens regularly under Office 2016 under Windows 10.

Multiple threads online point to the current "workaround" being to set Processor Affinity to 0, rather than utilizing all cores of the process. This seems like a shitty solution, and it would be better if the underlying issue(s) with using multi-core processor(s) would be fixed, so the workaround was no longer necessary. This bug dates back many years and has apparently never been properly addressed by Microsoft.

Basically Google "System Resource Exceeded" + "Affinity"...

Given the typical Dev/Test/Prod development staging methodologies, and the great ease by which changes to database objects (especially "supporting"-type changes like adding indexes to existing tables) can occur in a software development cycle, it would be very beneficial to allow the built-in Access Table, Query, Form, and Report designers to save the "state" of the overall object, and at "Save"-time offer an option to Generate VBA and/or SQL scripts that can help to facilitate the (re-)deployment of the new changes to partnering databases (migrate the changes from Test back to Dev or Prod copies of a database, for example).
Being able to (optionally) designate a database's SDLC Stage via pre-defined database properties and adding some supporting code appropriate to Dev/Test/Prod stages of a database file would be of great help as well.
Adding things like:
Having Access disallow dropping forms/queries/reports/code modules into DEV modes in a database marked as Production-level;
Adding additional prompts "This Database is designated as a TESTing database - Are You Sure?" before entering DEV modes for database objects in designated TEST DBs (and doing so even more emphatically when saving changes - offering the scripting options by default as part of the save operation);
Only designated DEV versions of the database files would have the same level of ease-of-use for editing operations we enjoy by default today.