Another GED conversion question

Moderator: MOD_nyhetsgrupper

Svar
Trent SC

Another GED conversion question

Legg inn av Trent SC » 22 jan 2005 02:26:06

Philip Cave
Another technical question for the fast-learning-but relatively-dense family
tree learner.
I've got two GED databases which have been worked on by different people at
different times. The first and older one is a bit of a mish-mash and has
over 8,500 entries, some of them questionable. And the second is much more
accurate, has around 500 entries and is an extract of the larger in its
contents.
Is there any way I can merge the two databases, telling the system that
merges them to give priority to the smaller database when it comes across
duplicates?
I use Family Historian and it may be that I can do this within this very
comprehensive program, but I'd rather ask the group's advice before I start
stuffing up my work!

Many thanks.

Ron

Re: Another GED conversion question

Legg inn av Ron » 22 jan 2005 05:05:45

Trent SC wrote:
Philip Cave
Another technical question for the fast-learning-but relatively-dense family
tree learner.
I've got two GED databases which have been worked on by different people at
different times. The first and older one is a bit of a mish-mash and has
over 8,500 entries, some of them questionable. And the second is much more
accurate, has around 500 entries and is an extract of the larger in its
contents.
Is there any way I can merge the two databases, telling the system that
merges them to give priority to the smaller database when it comes across
duplicates?
I use Family Historian and it may be that I can do this within this very
comprehensive program, but I'd rather ask the group's advice before I start
stuffing up my work!

Many thanks.


In Legacy the free version

you can view two files at one time and drag and drop records to the
other file
Also you can tag records 1 2 or 3 - the good file you could tag 1
plus I have not done this but I can see taht you could import one file
and assign a master source "reliable"

Then in legacy you can compare duplicate records and select the "reliable"

Perhaps FH has similar features

--
Ron Lankshear - Sydney Aust (from London- Shepherds Bush & Chiswick)
http://freepages.rootsweb.com/~lankshear/

Rich

Re: Another GED conversion question

Legg inn av Rich » 22 jan 2005 18:37:10

"Ron" <ronlank@hotmail.com> wrote in message
news:41F1D119.4080308@hotmail.com...
Trent SC wrote:
Philip Cave
Another technical question for the fast-learning-but relatively-dense
family
tree learner.
I've got two GED databases which have been worked on by different people
at
different times. The first and older one is a bit of a mish-mash and
has
over 8,500 entries, some of them questionable. And the second is much
more
accurate, has around 500 entries and is an extract of the larger in its
contents.
Is there any way I can merge the two databases, telling the system that
merges them to give priority to the smaller database when it comes
across
duplicates?
I use Family Historian and it may be that I can do this within this very
comprehensive program, but I'd rather ask the group's advice before I
start
stuffing up my work!

Many thanks.


In Legacy the free version
you can view two files at one time and drag and drop records to the
other file
Also you can tag records 1 2 or 3 - the good file you could tag 1
plus I have not done this but I can see taht you could import one file
and assign a master source "reliable"

Then in legacy you can compare duplicate records and select the "reliable"

Perhaps FH has similar features

Agree. Legacy is the best bet.


http://www.legacyfamilytree.com

However, it will take a lot of work. Another way with Legacy is to load
both GED files into a file and then use the merge function selecting the one
you want. I consider Legacy to have the best merge function available. No
matter how you do it a lot of careful work is required.

singhals

Re: Another GED conversion question

Legg inn av singhals » 22 jan 2005 20:21:43

Trent SC wrote:

Philip Cave
Another technical question for the fast-learning-but relatively-dense family
tree learner.
I've got two GED databases which have been worked on by different people at
different times. The first and older one is a bit of a mish-mash and has
over 8,500 entries, some of them questionable. And the second is much more
accurate, has around 500 entries and is an extract of the larger in its
contents.
Is there any way I can merge the two databases, telling the system that
merges them to give priority to the smaller database when it comes across
duplicates?
I use Family Historian and it may be that I can do this within this very
comprehensive program, but I'd rather ask the group's advice before I start
stuffing up my work!

Many thanks.



Personal Opinion formed after long and painful experience:

DON'T DO THAT

If nothing else, you'll pretty quick forget which 500 are "solid" and
which 8000 aren't. and anything fancy you do to remind yourself (such as
OK as the suffix on the 500) is bound to cause confusion at some point.
Best not to go there.

Granted, most import routines permit you specify WHICH of two records is
to become the primary which is to be merged into it, but that's 500
names worth of labor-intensive intellectual work which reacts badly to
distractions or interruptions.

Two separate databases is probably more fail-safe.

Cheryl

Gjest

Another GED conversion question

Legg inn av Gjest » 23 jan 2005 06:51:06

Trent SC wrote in a message to All:

TS> From: "Trent SC" <trent@invalid.invalid>

TS> Philip Cave
TS> Another technical question for the fast-learning-but
TS> relatively-dense family tree learner.
TS> I've got two GED databases which have been worked on by different
TS> people at different times. The first and older one is a bit of a
TS> mish-mash and has over 8,500 entries, some of them questionable.
TS> And the second is much more accurate, has around 500 entries and is
TS> an extract of the larger in its contents. Is there any way I can
TS> merge the two databases, telling the system that merges them to
TS> give priority to the smaller database when it comes across
TS> duplicates? I use Family Historian and it may be that I can do this
TS> within this very comprehensive program, but I'd rather ask the
TS> group's advice before I start stuffing up my work!

Merge booth into an existing database, or a new one?

If the latter, your originals would be preserved anyway.

Steve Hayes
WWW: http://www.geocities.com/Athens/7734/stevesig.htm
E-mail: hayesmstw@hotmail.com - If it doesn't work, see webpage.

--- WtrGate v0.93.p9 Unreg
* Origin: Khanya BBS, Tshwane, South Africa [012] 333-0004 (8:7903/10)

Austin W. Spencer

Re: Another GED conversion question

Legg inn av Austin W. Spencer » 23 jan 2005 09:36:37

On Sat, 22 Jan 2005 01:26:06 -0000, "Trent SC" <trent@invalid.invalid> wrote:

Philip Cave
Another technical question for the fast-learning-but relatively-dense family
tree learner.
I've got two GED databases which have been worked on by different people at
different times. The first and older one is a bit of a mish-mash and has
over 8,500 entries, some of them questionable. And the second is much more
accurate, has around 500 entries and is an extract of the larger in its
contents.
Is there any way I can merge the two databases, telling the system that
merges them to give priority to the smaller database when it comes across
duplicates?
I use Family Historian and it may be that I can do this within this very
comprehensive program, but I'd rather ask the group's advice before I start
stuffing up my work!

Many thanks.

As long as people choose a workable organizational scheme and hew to it
consistently, there is no reason for their files to turn out all hydra-headed.
Troubles begin when they simply (or rather, simple-mindedly) pile successive
waves of data into a single program or database without connecting it to their
existing information. Merging is the easiest way to totally derange an already
disorganized collection.

For all I know, you owe your 8000-person database to just such a policy. For
myself, I try never to take notes on anyone who doesn't connect to an existing
individual in my database. When I do my data entry, I can select that person
first and navigate from there. I don't rely on merges because I don't want my
tree to resemble a Frankenstein monster.

If I were to attempt this kind of project, I would want to begin by making a
list of *exactly* which individuals I'd need to merge. It helps if this list is
on paper if you plan to merge every pair more or less by hand, which I would, or
if you want to clean up after the merging routine. But any sort of list would
define the optimum result to aim for and also reduce the risk of computer error.
(Merging routines are not always tolerant of name variants, for instance.) Then
I would make a backup of the larger database before importing the smaller
database into it. Lastly, I would work my way through the list, merging
marriages as well as individuals where necessary. On one hand, there is no need
to tweak the larger database to prime it for the merges, or to rely on the
eccentricities of an automated process. On the other, the process is more time
consuming. But this is an open-ended project, right?

Austin W. Spencer

Rich

Re: Another GED conversion question

Legg inn av Rich » 23 jan 2005 17:36:55

I did a merge with a pretty big data base using Legacy. It required extreme
care and lots of time, (but less time than using other means). If you look
at the Legacy merge display you can see that most of the time you can be
very confident that you have two identical individuals. It displays on a
split screen, not only personal dataof both candidates, but parents,
siblings and spouses and children. There is an automatic merge feature
that can be enabled however for it to work there must be a complete set of
birth and other data for both individuals. I don't bother using it.

One item that would be nice is if they had a "Whoops, changed my mind"
button so you could recover from accidently pressing the "Merge" button.


If you buy the "deluxe" version you can mark pairs as not being related so
you don't have to review them every time you use the global merge.

Every now and then you may run into pairs where you are not certain. In
those cases you have to write them down, go back into the program and
determine if they are the same person. I still have a few that could be the
same but so far have not made the merge. For example a woman who is a child
in one family and a wife in another. I need more data to really verify that
they are the same.

On the bad side you can imagine the mess if you should merge an individual
with his grandfather!!

When performing such a procedure you make lots of copies and backups along
the way.






"Austin W. Spencer" <AustinWSpencer@cox.net> wrote in message
news:7go6v0lgfcnmehh3nmi9tc9e30ku1q5snr@4ax.com...
On Sat, 22 Jan 2005 01:26:06 -0000, "Trent SC" <trent@invalid.invalid
wrote:

Philip Cave
Another technical question for the fast-learning-but relatively-dense
family
tree learner.
I've got two GED databases which have been worked on by different people
at
different times. The first and older one is a bit of a mish-mash and has
over 8,500 entries, some of them questionable. And the second is much
more
accurate, has around 500 entries and is an extract of the larger in its
contents.
Is there any way I can merge the two databases, telling the system that
merges them to give priority to the smaller database when it comes across
duplicates?
I use Family Historian and it may be that I can do this within this very
comprehensive program, but I'd rather ask the group's advice before I
start
stuffing up my work!

Many thanks.

As long as people choose a workable organizational scheme and hew to it
consistently, there is no reason for their files to turn out all
hydra-headed.
Troubles begin when they simply (or rather, simple-mindedly) pile
successive
waves of data into a single program or database without connecting it to
their
existing information. Merging is the easiest way to totally derange an
already
disorganized collection.

For all I know, you owe your 8000-person database to just such a policy.
For
myself, I try never to take notes on anyone who doesn't connect to an
existing
individual in my database. When I do my data entry, I can select that
person
first and navigate from there. I don't rely on merges because I don't want
my
tree to resemble a Frankenstein monster.

If I were to attempt this kind of project, I would want to begin by making
a
list of *exactly* which individuals I'd need to merge. It helps if this
list is
on paper if you plan to merge every pair more or less by hand, which I
would, or
if you want to clean up after the merging routine. But any sort of list
would
define the optimum result to aim for and also reduce the risk of computer
error.
(Merging routines are not always tolerant of name variants, for instance.)
Then
I would make a backup of the larger database before importing the smaller
database into it. Lastly, I would work my way through the list, merging
marriages as well as individuals where necessary. On one hand, there is no
need
to tweak the larger database to prime it for the merges, or to rely on the
eccentricities of an automated process. On the other, the process is more
time
consuming. But this is an open-ended project, right?

Austin W. Spencer

mickg

Re: Another GED conversion question

Legg inn av mickg » 24 jan 2005 06:22:26

singhals wrote:
Trent SC wrote:

Philip Cave
Another technical question for the fast-learning-but relatively-dense
family tree learner.
I've got two GED databases which have been worked on by different
people at different times. The first and older one is a bit of a
mish-mash and has over 8,500 entries, some of them questionable. And
the second is much more accurate, has around 500 entries and is an
extract of the larger in its contents.
Is there any way I can merge the two databases, telling the system
that merges them to give priority to the smaller database when it
comes across duplicates?
I use Family Historian and it may be that I can do this within this
very comprehensive program, but I'd rather ask the group's advice
before I start stuffing up my work!

Many thanks.


Personal Opinion formed after long and painful experience:

DON'T DO THAT

If nothing else, you'll pretty quick forget which 500 are "solid" and
which 8000 aren't. and anything fancy you do to remind yourself (such as
OK as the suffix on the 500) is bound to cause confusion at some point.
Best not to go there.

Granted, most import routines permit you specify WHICH of two records is
to become the primary which is to be merged into it, but that's 500
names worth of labor-intensive intellectual work which reacts badly to
distractions or interruptions.

Two separate databases is probably more fail-safe.

Cheryl

No harm in keeping the originals too as a reference


MickG

Austin W. Spencer

Re: Another GED conversion question

Legg inn av Austin W. Spencer » 24 jan 2005 07:28:03

On Sun, 23 Jan 2005 16:36:55 GMT, "Rich" <nospam@att.net> wrote:

I did a merge with a pretty big data base using Legacy. It required extreme
care and lots of time, (but less time than using other means). If you look
at the Legacy merge display you can see that most of the time you can be
very confident that you have two identical individuals. It displays on a
split screen, not only personal dataof both candidates, but parents,
siblings and spouses and children. There is an automatic merge feature
that can be enabled however for it to work there must be a complete set of
birth and other data for both individuals. I don't bother using it.

I use PAF 5.2 for most purposes, and Legacy for GEDCOM testing and reports. The
merge dialog in PAF displays BMD (no baptisms, marriage licenses, or burials)
and the names of up to two spouses. I might like it better if I had confidence
in its ability to transfer user-defined events.

One item that would be nice is if they had a "Whoops, changed my mind"
button so you could recover from accidently pressing the "Merge" button.

If you buy the "deluxe" version you can mark pairs as not being related so
you don't have to review them every time you use the global merge.

Yeah, but who wants to keep these tags affixed for as long as one maintains a
database? At some point they are liable to confuse you, if no one else. This, at
least, is the way I interpret Cheryl's remarks on this thread. Yet it hardly
seems satisfactory to me not to add a collection of useful data to a database
just because the implementation is going to be difficult -- one way or another.
The way to proceed is to first make backups, to guarantee the integrity of the
existing data, and then proceed with the most fail-safe method of integration.

[snip the remainder]

Austin W. Spencer

Svar

Gå tilbake til «alt.genealogy»