I use Custom Groups in the Navigation Pane of Access to keep track of objects I am changing for various tasks, so I know at a glance what objects to submit to our update process.

Sometimes, the items in a Group will change. I'm not talking about linked tables or queries not showing after a relink. I'll have put FormA in the group, and when I open the database, FormA is no longer in the group, but FormD is. Same for report objects, modules and queries.

Problem is, I have not found a pattern of when this happens. Sometimes it's after a Compact & Repair. Sometimes after a Decompile. But most C&Rs and decompiles don't result in the problem, and sometimes nothing unusual happened. I closed the DB and when I reopened it, things were different.

It's not one specific database file, but many different ones.

Anyone else notice this problem and have any thoughts about a pattern?

(I'm in Access 2016 but version number doesn't matter, as I had the same problem in A2013, and A2010. I try to forget my A2007 experience completely.)

MS Office 365 email service provides various opportunities for businesses to standardize the requirement . Moving PST to Exchange Online can be formidable. EdbMails import PST to Office 365 utility does this job easy . You can migrate a particular folder or outlook data files that you want to migrate from a PST file to Office 365 tenant.

The solution supports the migration of PST files to Office 365 including emails with attachments, tasks, notes, contacts, and calendars.

Overview of its features:

Direct PST file migration to Office 365 tenants
No limitations on File Size
Supports Incremental migration. No duplicate items migration on consecutive migration on the same system.
Various filter setting options to migrate the specific data.
Highly intuitive Graphical User Interface.
Supports MS Outlook 2019/2016/2013/2010/2007 and below versions.
‘One time Payment’ - Lifetime license with a free software upgrades
24/7 Technical Support

Conclusion
In this, we discussed “How to Import PST to Office 365 mailbox account?”. You have got a quick solution to migrate Outlook PST file to Office 365. This automated solution easily imports the PST file.

EdbMails simplifies Office 365 Migration by automating the configuration and migration tasks. Effectively transfers the data between two Office 365 tenants. It allows you to migrate all the existing mailboxes, contacts and distribution groups, etc. from one Office 365 tenant to another. Its incremental migration feature avoids duplicates on the target mailbox.

Key Features & Advantages:

• It can perform as a single batch move that includes all of your mailboxes, contacts, and distribution group objects, etc.


• Designed with multithreading which improves migration speed and saves lot of time.


• Only the newly added items are migrated to your target server on consecutive incremental migrations which avoids duplicate items.


• Seamlessly migrate your Public folder data to Office 365 with all sub-folders and folder permissions.


• Easy to use user interface, automatic migration (without any Powershell commands) that reduces your time and resources.


• Supported with easy to use GUI, No Powershell commands involved, which reduces your time and resources.


• Automatically maps the source and target mailboxes for the migration operation. In addition, it allows you to manually change/map the target mailboxes.


• Allows moving the recent data with date filter settings and the user can start working with recent emails. Later the rest can be migrated without any downtime.

MBOX file is supported by 25+ email clients mailboxes such as Gmail, Apple Mail, SeaMonkey, Entourage, Netscape, Eudora & others. But no application exports the mailbox in PST file format. On the other hand, the manual process is useless with a large mailbox plus it does not maintain the folder hierarchy.
So if you want to export direct MBOX to PST format with all mail folder, inline images and attachment than adopt MailsDaddy MBOX to PST Converter. This is the most relevant program that no only migrate MBOX to PST format but also allows user to import MBOX file in Office 365, EML, MSG, HTML, MHTML, Live Exchange & RTF format. The MBOX converter has so many useful features that built on simple GUI interface. The user can also use the demo version first and convert first 20 emails from each mailbox without any cost.

For more information visit: https://www.mailsdaddy.com/mbox-to-pst-converter/

A fellow developer reported this fairly obscure bug to me as I work extensively with what I call 'deep hidden' tables using property dbHiddenObject (MSysObjects Flags=1). If a table containing data in attachment or multi value fields is 'deep hidden', the data APPEARS to be deleted from those fields. The data is NOT restored if the tables are returned to normal.
I have tested this and confirmed it to be true. I have also checked the contents of the related deep hidden system tables (each beginning with f_...) and the actual complex data is still present. However the user tables seem to have become detached from these.
For info, I found a workround by pure chance
I decided to test the third complex datatype - column history in long text/memo fields - by adding an extra field to the same table. To my surprise, the attachment / MVF field data was immediately restored.
The column history field doesn't need to be populated - it just needs to exist. Once that extra complex datatype field is added, deep hiding the table does NOT cause further 'loss of data' from the MVF/attachment fields. I have no idea why it works however!
Whilst it is unusual, to say the least, to use complex datatypes with deep hidden tables, it is a bug that I believe should be easy to fix.