RobJ

My apologies, Emile, a very troublesome girl Irma has sidelined me for awhile, with lots of volunteering before, during, and afterward, then hugely increased job demands afterward due to working for one of the few places with partial power (but not air conditioning!).  I have a lot of catching up to do with just about everything, especially computer stuff.

I can't think of anything to help though, as I haven't worked with reporting yet, except a specific report for troubleshooting.  Sounds like some of the family linking is not set up correctly.  I think there are others here with much more related experience that might have ideas about fixing that.

Thank you for your comments!

* Phantoms: The second Patrick O'Brien (in Rec#7) never had a spouse or child. I just added him to his parents for completeness, with practically no data.  That means Marriage Rec#7 should have belonged to another couple, but since there is no data in it (except his name) I don't know where it came from.  The phantom 'Unknown' person in Rec#18 can't be directly displayed, but I found I could get to him 'sideways' by clicking on a legitimate person, changing to Family View, then clicking on the '[Unknown]' person.  He had no name, but did have a birth and death fact identical to Anna's true spouse Laurence (1890-1985 Hamden).  And he has a child with no name but the same identical birth and death facts (1890-1985 Hamden).  Clicking on the child just highlights the [Unknown] person in the left list.  On a right-click, deletion and unlinking options are presented, but they don't work.  (This is all after the new 7.5.3 db cleanup.)  Thankfully, the Drag & Drop version of this db cleared him out completely, but it would be nice if the database cleanup tools could also do that, as well as remove any marriage records with only one spouse (unless intentionally added? with an unknown spouse?  not my problem! for RM to figure out!).

* Missing MRIN's: should be harmless, similar to deleting records, there would be missing record numbers.  In my picture above, Rec#14 and #15 are missing, no issue.  The Drag & Drop produces a db with them all renumbered from one, so if the missing ones bother you, a complete Drag & Drop should clean all of that up.  One thing I forgot to mention about Drag & Drop is that I was concerned whether the new db would be still connected to Ancestry.com.  (I'd completely forgotten about Jerry's comments about successfully dragging over one person!)  I can confirm the completely new db was still fully connected, every person to its Ancestry counterpart, *and* the hints were still 'Confirmed', no repeat of the hints.

* New marriage routine: that sounds like a good and safe way to do it, avoiding the potential issues.  Hopefully RM will figure it all out, and it won't be needed in the future.  Integrating partially incompatible systems is always hard.

* Sanity checks: (just a suggestion for the developers) it's been awhile since I was programming complex systems, with multiple programmers and subsystems, but one thing I used to like to do was add sanity check mechanisms, either fully doubly linked lists where I could completely rebuild systems on either side, no matter where the corruption occurred; or to add simple sanity check flags or ID's, that allowed early detection of issues before further corruption or errors occurred.  It could be as simple as adding a bitfield to the person record, where you could reserve a single bit for each critical item, like 'is there a marriage fact', 'a birth fact', 'a death fact', etc.  A db or record integrity check could easily and at any time determine if something is missing, wrongly linked, corrupted.  It could be a little more advanced by adding an additional marriage fact bit, 2 of them so that it can count 0, 1, 2, or '3 or more' marriage facts.  It requires a little more error checking logic, but pays off in cleaner records and systems, easier debugging, until you achieve a well-tested and stable system.

A follow-up, belated I know - I used Drag & Drop to create a new db, and used the new 7.5.3 db cleanup tools on a copy of the original corrupted db, just to compare.  Both worked roughly the same, producing a cleaner db with no marriage record corruption, but neither was perfect.  Both retained all marriage records with their correct couples, and both removed the wrongly linked data (marriage years and places) of the corrupted records.  Both removed the corrupted Rec#5, and kept the good Rec#5 with '1865'.  The Drag & Drop did not bring over the bad [Unknown] [Unknown] person, but left Anna Marion Nolan with the extra Marriage record with a phantom spouse (her only spouse is Laurence).  The new db cleanup did not remove the [Unknown] person, and in fact I could not find anyway to select them for deletion or unlinking.  They don't appear to have a person record, so they seem to be another kind of phantom that could be removed.

Neither removed Rec#7, with the second Patrick O'Brien and no spouse (a phantom spouse).  And the Drag & Drop created a second phantom spouse when it removed the phantom person.  This too seems like another cleaning improvement that could be made in the db cleanup tools.

Because of the problems still existing in the records, and all of the duplicated, tripled, and quadrupled facts in some records, I think it's best if I give up and use TreeShare to re-download the db from Ancestry.

Check out the Drag and Drop video

I'm happy to see this passion!  It's my opinion that data portability is going to become a very important product feature, in the near future.  That means widespread GEDCOM agreement, a consensus on a GEDCOM 6, whatever it may turn out to be.  GEDCOM HAS to win widespread acceptance, and genealogical companies need to be required to declare and maintain full compatibility with current standards.  The recent loss of certain ancestry tools (TMG, FTM, etc) has caused pain among a segment of genealogical users, and reminded others of the risks of all your eggs in one basket.  In my view, DNA testing and features are also causing some migration, especially toward public 'one world' trees.  Data portability should be an important requirement of all your tools.  It's clearly not now.

It's difficult for me to see how widespread agreement can be accomplished without the current gorilla, Ancestry.com.  But I believe it's in everyone's interest to get together and agree, even if it means Ancestry dictates some part of the agreement, parts of which may not be desirable to others.  To me, the most important requirement is that round trip data integrity between tools and sites is ensured. After that, the emphasis should be on allowing, importing, and exporting as much detail as possible, even if your tool cannot handle as much detailed info as another tool, or breaks it up differently.  There will probably always be some incompatibilities in field layouts.