Dear John S I know that we are used to having just one record for each person - but why is this? As far as I can see, the functionality I was suggesting would be better - not worse - than one record per person. One point I did not mention is that sometimes you DO NOT KNOW whether two records are the same person or not. (I had two Thomas Smiths, both born in 1799. I merged them using the present laborious method. Then I found I needed to de-merge them which is of course even more difficult. Under my suggested procedure, merging and de-merging would be straightforward to do. But not straightforward to program, I admit!) JOHN B On 17 January 2012 15:24, John Steed <brothers_keeper@msn.com> wrote: > To John Bibby > > Rather than have a database with duplicates that are connected together, > it is better to have each person only one time in the database. > > Have you use the Compare Two Databases routine that is in BK 6.5? > > I plan to do something similar to that with one database where you can > merge two people from the same database into one person. > So I am working on that currently. > > John Steed > > > ----- Original Message ----- From: "John Bibby" < > johnbibbyjohnbibby@gmail.com> > To: <BK@rootsweb.com> > Sent: Tuesday, January 17, 2012 9:06 AM > Subject: [BK] BK - need for an "is the same as" relation > > > I'm doing a lot of merging databases and getting a lot of duplicates. >> >> Duplicates need to be merged i.e. some data is on record R1, other data is >> on R2. Sometimes they match completely (i.e. both say 1 Jan 1950), >> sometimes they match partially (i.e. R1 says 1 Jan 1950; R2 just says Jan >> 1950, or just 1950); sometimes they are in conflict (R1 says 1950, R2 says >> 1951). >> >> Relationships are another thing - R1 may link with children and R2 with >> parents. >> >> At present all this has to be done by hand which I find is virtually >> impossible unless you write it all out and then copy everything over by >> hand - it's VERY tricky! >> >> However, could we not have an "is the same as" relation. In the above >> examples we would just have a link under "Add" which would be "Add an >> identity relation". (Or maybe you would introduce a new individual who is >> identical to R1 _and_ identical to R2.) >> >> When the identity relation has been established, all events and >> relationships for R1 would also apply to R2. You could then show these on >> the screen altogether and they could then be edited in the normal way. >> (Thus you would see the two birthdates for R1 and R2 on th screen >> together, >> and would decide which to keep.) >> >> I'd welcome views on this idea: Is it useful? Is it doable? >> >> JOHN BIBBY >> >> ------------------------------**- >> To unsubscribe from the list, please send an email to >> BK-request@rootsweb.com with the word 'unsubscribe' without the quotes >> in the subject and the body of the message >> >> >