Have restored last DB backup available (still lots work lost). If I try to empty the Recycle Bin I get the following error (which others have also reported in the forums):
"The DELETE statement conflicted with the SAME TABLE REFERENCE constraint "FK_Tabs_Tabs". The conflict occurred in database "dnn_54", table "dbo.Tabs", column 'ParentId'. The statement has been terminated."
But I can delete the pages one by one. All pages had different names BTW. This didn't causes any deletions of legit pages.
I then tried to move the same page to become a child of one of its siblings. This again caused it to not appear in the menu and not be accessible via it's old address. If I look under 'Pages', it's still a sibling of the intended parent, but if I click view, the breadcrumb and URL indicate it's a child!
Looking at the Tabs table reveals why: the
TabPath and ParentId fields have been updated, but not the 'Level' - that's still the same as the parent (1)! If I fix the Level manually in the Tabs folder, the page re-appears in the menu. That gets me thinking: if you hard delete a tab whose Level has got confused in this way, maybe this is messing up the cascaded delete in some way?
It seems it's bizarrely easy to create these "confused level" tabs - just creating a top-level tab, then editing its settings and making it a child of any of the top-level sections causes its Level to remain at 0, but TabPath and ParentId are updated. Moving confused tabs around via the arrows in 'Pages' causes more mayhem - e.g., all children of a top-level section were made Level 0 (and their own children Level 1), just because an unrelated confused tab was moved around.
Annoyingly though I so far haven't reproduced the loss of Tabs from the database, even after various deletions and emptying. Must be some combination of confused tab factors?