Thanks Ira, I remember we touched on this subject some time ago. I was interested to see if others had this problem before I suggested that you spend your valuable time on a program modification. Any time I merge files I 'loose' valuable middle name information and sometimes important surname variations from the 2nd db. My db contains mostly FrCdn families - some stayed in Canada, some migrated to the US, some returned to Quebec or other parts of Canada. You would be amazed at the variations in names and spelling of names in a culture where it was common to have three or four given names, and then there are the variations in surname which shift from one generation to the next and sometimes inconsistantly among siblings. The underlying rule in all my research is to never throw a datum away unless I'm sure it's an error. For me those name variations are extremely valuable data, without them I couldn't link relationships through time. I was hoping that someone might have an easier way around this instead of cutting and pasting off the bottom of the log file. Perhaps most of the listmembers are working with more static cultures where name variations are rare. Those of us with immigrant blood don't have it so easy :) Mike Whitehorse YT At 07:38 07/05/01 -0500, you wrote: >At 05:38 AM 5/7/01 +0000, you wrote: >>Does anyone else have a problem when merging databases that the program >>strips off the names in the 2nd database. I'm merging databases from >>distant cousins, and valuable variations in name get 'lost' to the log file. >>The 2nd db names are at the end of all the individuals in the log file and >>have to be retrieved by cut and paste... somewhat tedious. Why can't the >>program bring the 2nd db name over as a NALT event rather than sticking it >>in the bottom of the log file? > >A suggestion which I will add to my list. Never thought of doing it this >way. I always used the Log to check the name variations and then correct >the main name based on my own decision for each individual person. I seldom >wanted both names as typically one was incorrect or one more correct than >the other. > >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 ==== >You can contact the List Manager at: >[email protected] > >============================== >Visit Ancestry's Library - The best collection of family history >learning and how-to articles on the Internet. >http://www.ancestry.com/learn/library > >

>I was hoping that someone might have an easier way around this instead >of cutting and pasting off the bottom of the log file. >Perhaps most of the listmembers are working with more static cultures where >name variations are rare. >Those of us with immigrant blood don't have it so easy :) Actually, I suspect that it is a minority of users who ever use the Database Merge feature. I would guess that 90% of my users are basically using the program for smaller databases (say less than 3000 to 5000 names) and they are the only ones working in the family - meaning that they don't have GED files or databases from relatives that are being shared - thus the need for Split and Merge Database functions. I really don't know the percent - just making a gut feel guess based on what I hear from users. In fact, I think there are a rather significant number (say about 50%) of my users who deal with rather small databases of only a few hundred names. I regularly hear from people who only have 200, 300 or 500 names. 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, I guess I'm one of the few who truly appreciates the awsome beauty of what you've written. I find that the internet allows me to network and find many research cousins. A small gedfile is usually the easiest way to update each other's data. Selection lists are great!! I'm using the program to trace and document the ancestory of about six families who lived in the same region of Québec and migrated to Minnesota at about the same time. My database is approaching 7000, about 10% are direct ancestors. I think I know the answer, but is there a way to print that wonderful concise summary table that the relationship calculator produces? I tried to print it :( , and cutting and pasting is like trying to nail jelly to a tree. I ultimately used the relationship calculator in the report section, exported it as a text file, then edited out the many pages of redundent information to produce a concise report summarizing relationships between cousins. I've shared these concise reports with cousins who find them informative, and very helpful in visualizing our common genweb, especially when you're cousins at 12 different levels. Mike At 07:13 08/05/01 -0500, you wrote: > >Actually, I suspect that it is a minority of users who ever use the >Database Merge feature. I would guess that 90% of my users are basically >using the program for smaller databases (say less than 3000 to 5000 names) >and they are the only ones working in the family - meaning that they don't >have GED files or databases from relatives that are being shared - thus the >need for Split and Merge Database functions. I really don't know the >percent - just making a gut feel guess based on what I hear from users.