Jump to content


Photo

Merging duplicates can double up some facts


  • Please log in to reply
5 replies to this topic

#1 NoŽl Sant

NoŽl Sant

    Member

  • Members
  • PipPip
  • 10 posts

Posted 09 February 2007 - 06:55 AM

In a previous post, Alfred wrote:

QUOTE
You can replace:
1 SEX M<return>

with:
1 SEX M<return>
1 EVEN Benson<return>
2 TYPE Family Line<return>

to add a fact to everyone in a ged file which contained all the descendants of an ancestor.

So I used this technique, then imported the ged file back. Then I used Tools/Merge/Automatic merges, and left all boxes ticked.

Then, to compare before and after, I exported this as a gedcom file, and compared it with the previous one, the one I edited to give every body the new fact. The new facts were in a different order - just irritating when you're comparing a large file for other differences. BUT, some other facts had been duplicated. Some Notes facts, but not all, and an Alternate Name fact (I think there's only one in my database). Using RM to view the people concerned in the updated database, the facts had indeed been duplicated, though the people were merged.

I tried again using Duplicate search / merge and merged just the person with the Alternate Name. Looking at him directly in RM, he had the Alternate Name fact twice, again, with the same value.

Is this a known problem, or did I do something wrong?

Also, is there an easier way to compare two RootsMagic databases?


#2 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3493 posts

Posted 09 February 2007 - 02:40 PM

First a little "background" about that other discussion thread here:
http://www.rootsmagi...?showtopic=4590
Keep in mind that this procedure was offered as a "workaround" for something that RootsMagic does not currently offer! Four "separate" databases was your original objective and it was discussed about how hard that may or may not be to accomplish and work with, ETC., so you had resigned yourself to working all in one database.
QUOTE(NoŽl Sant @ Feb 9 2007, 07:55 AM) View Post
In a previous post, Alfred wrote:
to add a fact to everyone in a ged file which contained all the descendants of an ancestor. So I used this technique, then imported the ged file back.
When you resigned yourself to working all in one database, my suggestion and Alfred's "correction" was aimed at creating a NEW database with all individuals, NOT re-importing/merging into your current one. In my opinion, it is never a good idea to do this... unless absolutely necessary and -you- have "normalized" all the individuals to using the same conventions (fact-types, place names, date formats, case-sensitvity, ETC). In addition, a complete current backup should be performed before any operations like this (to be able to return to "last known good" database).
QUOTE(NoŽl Sant @ Feb 9 2007, 07:55 AM) View Post
Then I used Tools/Merge/Automatic merges, and left all boxes ticked.
A clarification is needed here. The individuals that you have "added" a fact/event TO will no longer be considered a DUPLICATE to the original person in your source database. Consequently, AUTOMATIC merge MAY NOT merge many of these individuals (RM's "rules" for this, are not public knowledge) and thusly, to be entirely "safe" (many/most/all ?) of them become a second set of "like-named" individuals in the database.
QUOTE(NoŽl Sant @ Feb 9 2007, 07:55 AM) View Post
Then, to compare before and after, I exported this as a gedcom file, and compared it with the previous one, the one I edited to give every body the new fact. The new facts were in a different order - just irritating when you're comparing a large file for other differences.
I understand your point, but RootsMagic ALWAYS exports these in a very specific order. Our suggested workaround was just a "means" to add a fact to each individual, not a way to change or "control" the order. (RM has a very specific scheme for ordering facts based on individual or family, type of fact/event, with or without date/description fields, ETC.)
QUOTE(NoŽl Sant @ Feb 9 2007, 07:55 AM) View Post
BUT, some other facts had been duplicated. Some Notes facts, but not all, and an Alternate Name fact (I think there's only one in my database). Using RM to view the people concerned in the updated database, the facts had indeed been duplicated, though the people were merged. I tried again using Duplicate search / merge and merged just the person with the Alternate Name. Looking at him directly in RM, he had the Alternate Name fact twice, again, with the same value.

Is this a known problem, or did I do something wrong?
What you describe here is entirely consistent with how "manual" merging (and it's use within Duplicate search/merge) works! After the merge, you should observe the result window for the individual (with Duplicate search/merge, it moves on to the next possible merge, but you ~should~ re-select the entry line above) and <Edit Primary> to remove duplicated facts, make note of multiple husbands/parents, match Place name spellings, date discrepancies, ETC.
QUOTE(NoŽl Sant @ Feb 9 2007, 07:55 AM) View Post
Also, is there an easier way to compare two RootsMagic databases?
I've not seen a "plausible" workaround, but perhaps someone else will "chime in". Hope this explains, a little further, about some of the operations in RootsMagic.

---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#3 NoŽl Sant

NoŽl Sant

    Member

  • Members
  • PipPip
  • 10 posts

Posted 11 February 2007 - 11:06 AM

Thanks for this reply. And don't worry, I was doing this entirely on a copy of my database, as an experiment..

I'll take up your suggestion of getting rid of duplicated facts as I go. Thanks.

#4 Alfred

Alfred

    Advanced Member

  • Members
  • PipPipPip
  • 5734 posts

Posted 11 February 2007 - 01:52 PM

QUOTE
Then, to compare before and after, I exported this as a gedcom file, and compared it with the previous one, the one I edited to give every body the new fact. The new facts were in a different order - just irritating when you're comparing a large file for other differences. BUT, some other facts had been duplicated. Some Notes facts,


Did you ever say which version of RootsMagic you were using?
The current version, as of FEB 11, 2007, is 3.2.4

I think it is fixed now, but with earlier versions, the GEDCOM export sometimes added blank lines to notes and sources.

Then, when you imported this GEDCOM to the original file, and merged it, the notes would be different because of these extra blank lines so they wouldn't merge, causing a duplicate fact with a near duplicate note.

--- By the way, you could just as well have unchecked the "Smart Merge" box, the Share Merge will merge all duplicates coming from the same database. (IT uses the UID number, only.)--- SmartMerge will also check all original people to see if there might be some there to merge, slowing things down a little bit.
Alfred

#5 NoŽl Sant

NoŽl Sant

    Member

  • Members
  • PipPip
  • 10 posts

Posted 12 February 2007 - 11:18 AM

QUOTE(Alfred @ Feb 11 2007, 07:52 PM) View Post

Did you ever say which version of RootsMagic you were using?
The current version, as of FEB 11, 2007, is 3.2.4

I was 3.2.1 and have now updated to 3.2.4.

QUOTE
I think it is fixed now, but with earlier versions, the GEDCOM export sometimes added blank lines to notes and sources.

Then, when you imported this GEDCOM to the original file, and merged it, the notes would be different because of these extra blank lines so they wouldn't merge, causing a duplicate fact with a near duplicate note.

I'll try again, then...

QUOTE
--- By the way, you could just as well have unchecked the "Smart Merge" box, the Share Merge will merge all duplicates coming from the same database. (IT uses the UID number, only.)--- SmartMerge will also check all original people to see if there might be some there to merge, slowing things down a little bit.

... and uncheck SmartMerge.

Many thanks.

P.S. When experimenting, I keep deleting and re-copying the copy database. But delete always seems to leave two files, the ones ending _EX.CDX and _EX.DBF. IS this intentional?

#6 Alfred

Alfred

    Advanced Member

  • Members
  • PipPipPip
  • 5734 posts

Posted 12 February 2007 - 12:41 PM

HMMM, I think I did hear about that a long time ago and, or course, I have forgotten it.

I suppose it is because the original delete didn't include these two newer files and no one thought to update delete procedure to include them.

If Bruce would get some decent Beta testers, this sort of thing wouldn't happen. tongue.gif

((Let's see, how many would it take to find everything? : rolleyes.gif
Assuming it has been doing this for two years and there are maybe three thousand users, that could be something like 6000 man years of testing to find this one thing.
I guess we are just going to have to put up with a few bugs getting through the screen door.

OR, Is it the Windows laugh.gif
Alfred