When you are merging two databases, how do you tell the program to combine all the names when merging matched individuals? Mike

At 04:10 PM 3/10/01 +0000, you wrote: >When you are merging two databases, how do you tell the program to combine >all the names when merging matched individuals? You start by matching two people who you know are matches. Then it will ask if you want to merge relatives - this will kick int he routine that tries to match spouse, parents, children etc and if a large databse could go on for a long time as it matches these people up. BUT if names are different, it will stop and ask you to match names up. The slightest difference in spelling of names will cause it to stop and ask you to intervene here. But it is a matter of drag and drop to match up the proper names in this case. The Database merge is one of the most complicated parts of the program and I know there are still problems. I just merged a 8,000 name database with my 22,000 name database - with about 2,000 overlaps and I am still cleaning up long afterwards. The problems I see appear in multiple marriages - especially when the two databases disagree as to the true parents. This often occurs when say the father has married twice and the two databases disagree as to which of the two wives is the mother of the child. Or other cases where one database has a father but no wife and the other does have more than one wife and the children either don't get attached to any int he final database, etc. I am trying to document and fix these. But you can begin to see some of the complications that arise with a database merge. The cleanup afterwards really takes some human intervention as I have to make a decision about who the correct parents are when the two databases disagree. Ira ------------------------------------------------ Mr. Ira J. Lund E-mail: [email protected] Web: http://www.cf-software.com Cumberland Family Software, 385 Idaho Springs Road, Clarksville TN 37043

Ira, Thank you for your kind words of advice and positive encouragement. In the past month or so I've come through the steep part of the CFTv3 learning curve. I'm taking the time to share my observations since only you can determine if program changes or improvments are needed. My situation is probably not unique. I'm the first one of my family branch to become cyber-savy and take an interest in genealogy. I started at the beginning of February with only a list of my great and g2 grandparents and where they lived and died. Some dilligent net searching with Copernic2K located three 'cousins' with gedfiles containing some data on my branch. My family records fell in the 'grey' area in the midst of three datasets. As you can imagine not every family remembers a distant cousin or great uncle with the same details, people are remembered by different names throughout their lives and birth surnames are sometimes not the spelling on the gravestone. Your program has been a very valuable tool for assembling a coherent picture of my ancestory. I've learned a few lessons along the way. The first hard lesson was that not all gedfiles use the standard event coding found in CFT. A significant amount of 'pre-processing' of the gedfile with a text editor is required to extract all the data. The error log generated by importing a gedfile is very useful in this regard, though it requires multiple imports to get an accurate copy of the original gedfile into a cft database file. Every minute spent editing the gedfile saved at least ten minutes editing the imported database. The next hard lesson is that imported gedfile databases must be dilligently edited for duplicate individuals, and incorrect links like people in the wrong family, BEFORE any index rebuild should be run. Running the index rebuild seems to crystalize errors and makes editing so difficult that it was often easier to delete the db and start over again. I had much more success and significantly less frustration when I refrained from rebuilding until all the editing and verifying was complete. Lesson three, merging.. Yes this is the most powerful tool in the CFT program. However imported databases must be thoroughly edited, before merging. The split screen of the merge window is very useful with it's drag and drop matching capability. But, what is really needed is one split screen window showing ALL the events for two merge candidates. It is frustrating to only see the details of one at a time. A split window like the delta function but showing all data not just the differences would be really useful. As well, this would be the best time to edit events before merging. For example, one db might have only the year and the other db the specific date. Deleting the unnecessary or redundant data at this stage would be way more time efficient than trying to track it down in the merged db. I'm only dealing with a 6000 person merged db with about 500 common individuals, but I doubt If I can find all of them to edit the merged events, while it would have been so simple at the merge screen. The only real problem I found with CFT is that it won't merge name data. For example, one db might only have a given and common name with a respelled surname, while the other db might have the full birth name data. The French-Canadian church was great at keeping records, however birth names of record often differed from names used in day to day life or when a family emigrated to the USA. It would be really useful if the program placed any different names into notes when individuals are merged rather than completely discarding the name data from the secondary db. Going back and re-inserting the additional name data from the secondary db is laborious, and the program should be doing this instead while it has the data 'in hand'. Much like the situation with importing gedfiles, the program's recommendation to rebuild indexes immediately after merging is NOT a good idea. The merged file must be thoroughly verified and edited where necessary BEFORE re-indexing, otherwise errors will become difficult if not impossible to fix in the re-indexed db. In my experience re-indexing is the last thing to do in the merge process. I deleted many days of work learning this valuable lesson. One of the most valuable tools I use is v3 and v2 running simultaneously. This is especially useful when verifying and editing merged files. I have the merged db in v3 and the source db on the v2 screen. I'm also finding a 'problem' with merged files where multiple marriages occur, or where additional marriage events appear, apparently out of nowhere. FrCdns often married twice but three or four marriages is anomalous. The only solution I've found is to dilligently verify against the original gedfile db on the v2 screen. One little 'bug' in the merge all relatives routine. I've had to drag and drop the same people into match over and over when I find another key matching individual. I am thoroughly enjoying the learning experince of running CFT. None of my comments are meant as criticism of an excellant piece of work, but rather areas where you might consider program development or additions to the manual. thanks for your valuable time, Mike Peltier Yukon Territory, Canada At 07:49 12/03/01 -0600, you wrote: >At 04:10 PM 3/10/01 +0000, you wrote: >>When you are merging two databases, how do you tell the program to combine >>all the names when merging matched individuals? > >You start by matching two people who you know are matches. Then it will ask >if you want to merge relatives - this will kick int he routine that tries >to match spouse, parents, children etc and if a large databse could go on >for a long time as it matches these people up. BUT if names are different, >it will stop and ask you to match names up. The slightest difference in >spelling of names will cause it to stop and ask you to intervene here. But >it is a matter of drag and drop to match up the proper names in this case. > >The Database merge is one of the most complicated parts of the program and >I know there are still problems. I just merged a 8,000 name database with >my 22,000 name database - with about 2,000 overlaps and I am still cleaning >up long afterwards. The problems I see appear in multiple marriages - >especially when the two databases disagree as to the true parents. This >often occurs when say the father has married twice and the two databases >disagree as to which of the two wives is the mother of the child. Or other >cases where one database has a father but no wife and the other does have >more than one wife and the children either don't get attached to any int he >final database, etc. I am trying to document and fix these. But you can >begin to see some of the complications that arise with a database merge. >The cleanup afterwards really takes some human intervention as I have to >make a decision about who the correct parents are when the two databases >disagree. > >Ira > >------------------------------------------------ >Mr. Ira J. Lund >E-mail: [email protected] Web: http://www.cf-software.com > >Cumberland Family Software, 385 Idaho Springs Road, Clarksville TN 37043 > > >==== CFT-WIN Mailing List ==== >To unsubscribe from CFT-WIN, send an e-mail message to: > [email protected] (for individual messages) > [email protected] (for Digest mode) >Subject: unsubscribe >In the body include only one word: unsubscribe >(Turn OFF your signature file when sending this command) > >============================== >The easiest way to stay in touch with your family and friends! >http://www.myfamily.com/banner.asp?ID=RWLIST1 > >