ROOTSMAGIC-USERS-L Archives

From:
Subject: Re: [RMagic] Sharemerge
Date: Sat, 31 Jan 2004 15:18:04 EST

While this doesn't directly address what you describe, if you want to find
people with more than one birth event, just do a Fact List ("Reports > Lists >
Fact list") and ask to print everyone with more than one birth fact (or death
fact, etc).

- Bruce
http://www.rootsmagic.com



In a message dated 1/31/2004 12:32:22 PM Mountain Standard Time,
writes:
I've been playing with Sharemerge. This is the facility whereby you can
export some GEDCOM, send it to your cousin, your cousin can import the
GEDCOM and do some updates, your cousin can then export the GEDCOM, send it
back to you, you can import it, you do a Sharemerge, and your cousin's
updates are now reflected in your database. In theory, it's a really neat
facility.

But I think there's a problem that renders the facility nearly useless.
There's a little bit of discussion in the archives about Sharemerge, and
there are recommendations for improvement. But none of the messages really
explain what the problem is. I can recreate the problem with a database
containing only a single person. Here's what I did.

1. Create a database called DOE1.

2. Create a single person, John Doe, born about 1925.

3. Export the entire DOE1 data base as a GEDCOM.

4. Import the entire GEDCOM into a second database called DOE2.

5. Change John Doe's birth date to 1 Jul 1925.

6. Export the entire DOE2 database as a GEDCOM.

7. Import the entire GEDCOM into the original database DOE1.

8. There are now two people in DOE1, John Doe b. about 1925, and John Doe b.
1 Jul 1925.

9. Perform a Sharemerge.

10. There is now one person in DOE1, namely John Doe born about 1925 and
also born 1 Jul 1925. In other words, there are two birth facts for John
Doe.

I find it entirely reasonable that both birth facts exist for John Doe after
the Sharemerge. I would not expect RootsMagic to properly guess which one
to keep, and I would expect to clean up the duplicate birth facts myself.
In a one person database it's not hard to find all the people that got
Sharemerged. But in a large database, I don't know how you would find them
all. There could be hundreds or thousands of people who need to be cleaned
up. The problem is that you can't find them, and so I'm extremely reluctant
to use Sharemerge.

It seems to me that there would be two solutions. One solution would be for
there to be a manual mode for the Sharemerge, where I would be presented
with the people being merged one at a time, and I could do the cleanup as I
merged. The other solution would be for the Sharemerge process to create a
log of the people who had been merged so I could use the list after the fact
to do cleanup. The second solution has been proposed in earlier messages,
even though the problem wasn't discussed in detail. With either solution, I
would not want to be presented with merged people whose entries were
identically equal. I would only want to be presented with merged people
where something had changed. I would expect the people whose entries were
identically equal to be Sharemerged automatically even in a manual mode, and
I would not expect them to appear on any report.

This thread:

• [RMagic] Sharemerge by "Jerry Bryan" <>

  • Re: [RMagic] Sharemerge by