Comments on a few statements: >The first hard lesson was that not all gedfiles use the standard event >coding found in CFT. Although I am certain that CFT is not 100% error free I believe that all the main standard events should be treated the same in all programs - but there is so much variation in different programs and how they create GED file that it is a real headache and quite difficult for me to anticipate all possible combinations. (GED import is the 2nd most difficult part next to Database Merge! GED export on the other hand is actually quite easy because in this case I only have to deal with CFT data.) >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. If you mean that you import GED files into your main database, I wouldn't do this. I would import a GED to it's own database first - then do the Database Merge. But it sounds liek this is the way you do it. If you mean that the GED file already has problems - duplicated infor itslef, then yes, you are right. I have seen the same thing myself - mistakes in the data which I wanted to merge with my own database - and yes, any of that that can be cleaned up before the merge would be good! >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. Good suggestion. Thanks. In fact perhaps this should simply replace the 'delta'. >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. Currently the comparison list basically only compares the two name lists side by side. It does no merging. To do what you suggest above would be an entirely different sort of approach - perhaps actually merging as you mess with the list?!? Actually allowing the merge to take place one person at a time as you mess with the list and making event changes at that point. (If you see what I mean.) Otherwise there would have to be some sort of external record kept of all the various events and what it was that needs to be done to the events at the time the full merge takes place. Anyway, we are talking some real complicated stuff here - in any case. I'd have to do some serious thinking here. >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'. In my case I walk through my log file (in the case of the last merge I'm talking about 2000 individuals - and it will take me many hours - weeks to complete) and see the name differences (and the event differences) and edit them as I need to. In my case I really don't want the program to be doing anything automatic with the names (or even differences in events). I want to see them myself and make my own judgement as to which is correct and whether I want to place part of the name from the second database into the main. I think this is one of those cases where I feel I just have to buckle down to good old hard work and forget about anything automatic. Knowing users the way I know them, as soon as I added anything automatic here, it would only satisfy one person and another would want it to do something automatic a different way and before I know it there are a zillion variations and even then each user will end up checking every name again anyway because they will then realize that even if the automatic way fixed most names there are so many that it fixed incorrectly that they'll have to manually check each one anyway. Besides a lot of work on my end to write such a routine for what I feel would not be much benefit. >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. > >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. I think the Rebuild problem is related to the multiple marriage problem. When the marriages don't get set correctly, the Rebuild attempts to repair them. I have been trying to look at this multiple marriage problem in the Database Merge more closely - recently. >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 have noticed this also. At one time I had done something with part of this and reduced it somewhat. I will have to look again. 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

At 07:26 14/03/01 -0600, you wrote: >Comments on a few statements: > A split window like >>the delta function but showing all data not just the differences would be >>really useful. >Good suggestion. Thanks. In fact perhaps this should simply replace the >'delta'. Yes, this would be a good soluition since all the functions are already in the delta command. I would find a comparitive listing of all events more useful than just the differences. What do you other listmembers think about this? >>As well, this would be the best time to edit events before merging. >> 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. > To do what you suggest above would be an >entirely different sort of approach - perhaps actually merging as you mess >with the list?!? Actually allowing the merge to take place one person at a >time as you mess with the list and making event changes at that point. (If >you see what I mean.) Yes that's exactly how I visualized it working. Sort of like interactive processing, rather than 'batch processing ' like now. One would merge a family group at a time, much like the drag and drop frature in the merge all relatives merge Otherwise there would have to be some sort of >external record kept of all the various events and what it was that needs >to be done to the events at the time the full merge takes place. Anyway, we >are talking some real complicated stuff here - in any case. I'd have to do >some serious thinking here. Yes I also thought of somehow 'flagging' just the events to be merged., but that seemed like it would be more compilcated than just doing the merge one group at a time. >> 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. > > as soon as I added anything automatic here, it >would only satisfy one person and another would want it to do something >automatic a different way and before I know it there are a zillion >variations and even then each user will end up checking every name again >anyway because they will then realize that even if the automatic way fixed >most names there are so many that it fixed incorrectly that they'll have to >manually check each one anyway. Besides a lot of work on my end to write >such a routine for what I feel would not be much benefit. > I'm not suggesting automatic merging of names, you're right, no one would be happy with automatic combinations. I'm only suggesting that the secondary db name data be placed into a NOTE rather than being discarded as is the case now. It would then be easy to manually cut paste and edit the useful information into the main name field. Much easier than retyping or cutting and pasting the names from the log file. > >I think the Rebuild problem is related to the multiple marriage problem. >When the marriages don't get set correctly, the Rebuild attempts to repair >them. >Ira Yes, the rebuild is very powerful. and the repair function is great if the family relationships are correct, however it will only complicate mistakes in the merged db, and make them much more difficult to track and remove.. That's why I found that it was best to avoid rebuild until the merged db was completely edited. Premature rebuilding was the source of most of my db merge problems. The program's advice to rebuild immediately after a merge is misleading and perhaps should be rephrased., Mike >------------------------------------------------

Mike, Good and usufull comments. I agree 100% Leonel Finotti Campinas SP Brasil [email protected] ----- Original Message ----- From: "MJ" <[email protected]> To: <[email protected]> Sent: Quarta-feira, 14 de Março de 2001 19:05 Subject: Re: [CFTW]gedfiles and merging > At 07:26 14/03/01 -0600, you wrote: > >Comments on a few statements: > > A split window like > >>the delta function but showing all data not just the differences would be > >>really useful. > >Good suggestion. Thanks. In fact perhaps this should simply replace the > >'delta'. > > Yes, this would be a good soluition since all the functions are already in > the delta command. > I would find a comparitive listing of all events more useful than just the > differences. > What do you other listmembers think about this? > > >>As well, this would be the best time to edit events before merging. > >> 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. > > > To do what you suggest above would be an > >entirely different sort of approach - perhaps actually merging as you mess > >with the list?!? Actually allowing the merge to take place one person at a > >time as you mess with the list and making event changes at that point. (If > >you see what I mean.) > > Yes that's exactly how I visualized it working. Sort of like interactive > processing, rather than 'batch processing ' like now. > One would merge a family group at a time, much like the drag and drop > frature in the merge all relatives merge > > Otherwise there would have to be some sort of > >external record kept of all the various events and what it was that needs > >to be done to the events at the time the full merge takes place. Anyway, we > >are talking some real complicated stuff here - in any case. I'd have to do > >some serious thinking here. > > Yes I also thought of somehow 'flagging' just the events to be merged., but > that seemed like it would be more compilcated than just doing the merge one > group at a time. > > >> 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. > > > > as soon as I added anything automatic here, it > >would only satisfy one person and another would want it to do something > >automatic a different way and before I know it there are a zillion > >variations and even then each user will end up checking every name again > >anyway because they will then realize that even if the automatic way fixed > >most names there are so many that it fixed incorrectly that they'll have to > >manually check each one anyway. Besides a lot of work on my end to write > >such a routine for what I feel would not be much benefit. > > > > I'm not suggesting automatic merging of names, you're right, no one would > be happy with automatic combinations. > > I'm only suggesting that the secondary db name data be placed into a NOTE > rather than being discarded as is the case now. > > It would then be easy to manually cut paste and edit the useful > information into the main name field. > Much easier than retyping or cutting and pasting the names from the log file. > > > > >I think the Rebuild problem is related to the multiple marriage problem. > >When the marriages don't get set correctly, the Rebuild attempts to repair > >them. > >Ira > > > Yes, the rebuild is very powerful. and the repair function is great if the > family relationships are correct, however it will only complicate mistakes > in the merged db, and make them much more difficult to track and remove.. > That's why I found that it was best to avoid rebuild until the merged db > was completely edited. > Premature rebuilding was the source of most of my db merge problems. > The program's advice to rebuild immediately after a merge is misleading and > perhaps should be rephrased., > > Mike >