Yesterday was a nightmare of a day, recovering a Tree with Gramps. And it might be because it is still a day before All Hallows’ eve, but I’m not confident that I’ve woken from that nightmare,
Note: This is not my main tree. Hopefully, it will be a future downloadable Tree for exploring some real-world data in Gramps.)
In the discussion from Can't export GEDCOM, can't import Backup .gpkg into new Tree: @ennoborg and @PLegoux identified a corrupt handle that was why Gramps crapped out exporting a Tree as a GEDCOM and created unusable Backup files.
So I double unzipped (once for the .gpkg, again for the .gramps) the XML file and then stripped the following offending tag out of George Herbert Walker Bush’s Person. (The NULL handled hlink tag was originally generated by a beta version of the Photo Tagging Gramplet.) That single fix allowed the Backup to load and the GEDCOM to work.
<objref hlink="_">
<region corner1_x="87" corner1_y="66" corner2_x="99" corner2_y="75"/>
</objref>
The bad data had been cut out and the Tree was functional again… but it just seemed that way on the surface. The cancer went deeper.
Opening the Families view froze Gramps for a couple minutes. And opening the People Editor for G.H.W.Bush just spawned a 1 inch square blank window. The Relationships view was blank when George was the Active Person. However, the bottombar Gramplets showed data.
George’s family was corrupt, but how? (So many satirical political wisecracks clamor to be posted) It was a freshly imported XML file. Shouldn’t the Tree structure have been reconstructed and validated? But his family was still bad and Gramps gave no clue about the nature of the corruption.
Running the Check and Repair Database flagged some minor repairs. So I exported the Repaired Tree, make a new backup and imported again.
The same problems persisted. Gramps choked on George’s family.
Expanding the newly imported backup .gpkg created a file to inspect. But the 3MB XML file is a lot to swallow. Narrowing the inspection to JUST George did not reveal anything obvious. But even a minimal Person Profile spiders off to a multitude of secondary objects.
So I decided to treat George like a cancer. I export the corrupt individual off to a separate tree. That clone could be cleaned in detail.
(The clone had some empty families that were problematic to browse. The media chunk and any objref tags were eradication targets since Photo Tagging caused the cancer. <bookmarks> & <tags> chunks… gone. As were the tagref (tag reference) statements in the Person chunk. The cleaned clone passed an import and browse test in a blank tree.)
Once the clone was validated, the cancer-ridden Tree began treatment. Maybe the cancer was operable. Excising George seemed to make the views and George’s immediate relatives browsable again.
Remove Unused Objects… (twice) allowed interactive excision of George’s orphaned secondary objects (Citations, Events, Notes) and then their orphaned secondary objects (Citations). I made the mistake of leaving the orphaned Places, Notes markup for links and a Photo tagging rectangle.
After transplanting the cleaned clone via import, the families were stitched back together. Then the duplicates were tracked down and merged. The tree is in remission.
Note: My first transplant failed. The view problems recurred. The initial clone cleaning missed families. So the families chunk was lopped off in the XML before the next attempt. The next Transplant was more successful. But where the transplant would have created duplicates (Families, Notes, Places, Repositories, Sources, Citations, Media objects), the second transplant meant there were triplicates to be merged. I don’t know WHY the Places, Repositories, Sources or Media objects duplicated. They were identical Handles, IDs and content. I expected duplicate People, Notes, andCitations.
Looking back, I should have flushed the Person handle from George’s clone XML before importing. It would have been better if that object had been seen as a foreign and different person during import. The weird way he automatically spliced in among his parentless siblings while his parents had a childless marriage points to one (or both) of those family units being malignant. Maybe the George’s childref handle had not been excised when George was originally deleted?
The structure seems to be fixed now. But the Tree looked okay until I tried to open the Person Editor and Relationship view for George too.
Where else will this US Presidential History lineage be riddled with cancerous corruption? (Again, too many obvious mockery targets there. Maybe I just need to strip out the Living ex-presidents? The mere proximity of Tᴙump may be twisting reality.)
