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.