Another GED conversion question
Moderator: MOD_nyhetsgrupper
-
Trent SC
Another GED conversion question
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.
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
Trent SC wrote:
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/
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
"Ron" <ronlank@hotmail.com> wrote in message
news:41F1D119.4080308@hotmail.com...
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.
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
Trent SC wrote:
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
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
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)
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
On Sat, 22 Jan 2005 01:26:06 -0000, "Trent SC" <trent@invalid.invalid> wrote:
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
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
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...
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
singhals wrote:
MickG
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
On Sun, 23 Jan 2005 16:36:55 GMT, "Rich" <nospam@att.net> wrote:
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.
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
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