Update on RM9/10 Performance issues

Just to update everyone the source of the severe performance issue was the combination of trying out merge all citations and being forced to do a drag n drop to get around the bug in merging place details when your PlaceId exceeds 32768. Sorry to the people that don’t like us talking technical, that’s the only way to describe it. The long and short was I ended up with 4 times the citations (over 100,000) and over five million media links.

On the RM side I needed to forcibly remove citations and media links via SQLite to regain an operational database. That’s the good news. The bad news is I meticulously push all my updates to Ancestry.com, and pull them into a Family Tree Maker database which I use to search for duplicates which RM seems not to find, and do some reporting. Yes I know, doing that means tens of thousands of clicks.

The end result has been my Ancestry tree has four times the media due to the citation duplication, and attempting to delete it using Family Tree Maker resulting is that database being currupted. The not so politically correct terminology for both by Ancestry tree and my FTM database is totally f**ked.

I have the counts between my Ancestry and RootsMagic trees within 17 at this point, so I guess I have to take a flyer in those 17 and push a whole new tree to Ancestry, lose all the hints, and and suck it up. RootsMagic is my master, but that Ancestry tree has been there since Ancestry existed so blowing it away is sad, but it looks like that’s the only option.

I may wait until FTM 2024 comes out to see if they have any better cleanup options, but I’ve spent all week so far any only removed 5000 media items over the 60,000 that are dupes. Doesn’t look good.

1 Like

This is horrendous! Ancestry is a lost tree and a hint disaster but could you not go back to a functional tree using time machine backups? You may lose some recently entered data but still be better off. Also the FTM file could step you back up to 1000 changes to perhaps recover that file.

My master tree is in RootsMagic, and is close but not totally in sync with Ancestry. When the massive duplication in RM took place I needed to manually manipulate the RM database to remove them. Unfortunately there’s no way to do that type of activity in FTM because their database is proprietary and encrypted. There’s also no way to remove large quantities of images in Ancestry.com.

So can I get the database back, sure. I could download it from ancestry.com, go back to my last FTM backup, or use Time Machine. Then I’ll need to redo the thousands of click, wait, delete, click, wait, delete, etc. It took all day yesterday to delete 3000 images, and I have about 40,000 more to go. Continuing with that process isn’t practical, and the FTM database going south was the nail in the coffin.

So, I’m going to get my RM database as close to in sync as possible with tree share, then blow away my ancestry tree, upload a completely fresh one from RM using TreeSHare, then pull down that one from ancestry using FTM.

Consider trying to find a decent pre disaster time machine version before committing to thousands of clicks in RM. FTM does have a 1000 step change back option.

Actually uploading a fresh tree to Ancestry avoids thousands of clicks in RM. Essentially the least click, most expedient option. FTM going back 1000 changes helps me not, as that just means doing them over, and can’t undo changes on the main ancestry tree.

None of the options in front of me are appealing, and at this point all options involve deleting the Ancestry tree and reuploading as that’s the only way to get rid of the 40,000 extraneous images in the online tree.

Going back to “pre-disaster” means reloading my backup from 11-29-2023, capturing all the changes since then, drag N drop to a clean database to fix the original issue with PlaceId then reapply the changes, reexport/import the configtable to recover my books, then I still have thousands of clicks to sync that back with Ancestry, and my FTM database still needs to be reloaded from Ancestry.

Losing the FTM database is annoying, but the least of my problems at the moment. On top of that I have no guarantee that reloading the backup FTM database and redoing the changes won’t cause it to flip out again and I’d be right back where I started. The core issue is the huge volume of extraneous images, so reloading a backup doesn’t fix that.