|Merging in TMG|
|Applies to v5.x and higher although the principles apply to earlier versions|
|Merging in TMG refers to the combining of various records so
that the user will be able to work more efficiently and/or present
his research in a more accurate manner. When any kind of
operation such as this is planned, be sure to make a backup
before you start to eliminate any problems that may result from any
of the process being contemplated.
|There are six types of merging in TMG. You can merge:
There are also four ways of merging data in TMG. They are all similar in that one type of record of group of records is essentially added (appended) to another of the same type and the first may or may not be affected. The four methods are:
The first three methods are somewhat automated while the last is
completely manual since it has the greatest potential for losing
data in an automated process.
|Projects and Data Sets
The first and easiest method to understand is that of projects and data sets. That is, you can merge one project with another project and only the one project is affected. For example, if you merge project B into project A then project B is "tacked on" to the end of project A. Thus project A is affected, but project B remains the same. You may then leave project B or you may manually delete it as you see fit. So if the project each had two data sets before the merge then the before and after would be like this:
You can also merge project A into project B and the result is
|Data sets are merged in a similar way to projects.
The difference is that the ID numbers of the merging data set will
be re-numbered based on the highest ID number in the merged into
data set. So lets assume we are merging data set 3 above in
project A above into data set 1. The data sets looks like this
before and after the merge:
Note that after the merge, ID#16 in data set A will be the person who was numbered #1 in data set B. Also note that data set B has not been affected.
|Merging of Sources and of Repositories is different in
that one record is always destroyed after the merge. Here, the
two records be merged are considered to be exact duplicates (or the
decision is made that they are essentially the same. You would
select one of the two records to retain (we'll call it the "master")
and the other (we'll call it the "duplicate") is deleted
after the merge. Records like this usually have many other
records connected or attached to them. During the merge, all the
records connected/attached to the duplicate record (the one to be
deleted) will be changed so that they will now be connected/attached
to the master record (the one to be retained). After
this/these changes, the duplicate is no longer needed and is
deleted. TMG does not care which of two records is retained
and which is deleted. You need to make this decision. In
some cases, you may "flip a coin" to decide and in other cases, the
decision is obvious as to which should be retained. In all
cases, you will want to review both records to see that one or more
pieces of information is not lost. That is, you may choose to
declare one record as the duplicate but it has some information that
is not in the master record. You will need to add that
information to the master record before the merge.
The third merge method is that of persons. It is similar to that of Sources and Repositories in that the duplicate person is deleted after the merge is complete. The difference is that you may select to retain or not retain certain data (Tags). For example, suppose that person A has a normal Birth Tag with data from a birth certificate and person B has a Birth Tag with a date that you entered as an estimate. Since you do not need the estimated date after the merge, you may choose not to include that person B Birth Tag. On the other hand, if the person B Birth Tag has data from the family Bible, then you will want to retain both Birth Tags for later processing (in the next section).
Thus you need to be careful here because while some Tags may appear to be duplicated or they may only be partially duplicated. Also, one record may contain inaccurate data which you want to retain for future reference. Further, the data may be duplicated but the Source Citation may be different.
After the merge, like Sources and Repositories, the duplicate person is deleted. But the retained person will have all the retained Tags from both persons. By default, all Tags are to be retained.
Again, TMG does not care which is selected as the master and which is the duplicate. I usually select the lower ID# as the master. That is just personal preference, however.
|Merging Tags and Manual Merges
The fourth method of merging is really just a manual copy/paste/delete process and would almost apply to everything except projects and data sets. However, we will discuss it here in relation to Tags that are or appear to be duplicated for a person. The earlier methods all were somewhat automatic in nature. While many users have requested a more automated approach to merging Tags for a person, the copy/paste/delete process remains the only reliable method at this time.
The reason for this process is usually due to merging of persons. In most cases, there can be at least one duplicate Tag -- the Primary Name Tag and a non-Primary Name Tag that is either the same name or only slightly different. There may also be duplicate or near duplicate Tags in the other Tag Groups -- Address, Birth, Marriage, Divorce, Death, Burial, Other, History, and Relationship. The number of duplicates will vary from person pair to person pair.
This method requires the user to examine the various fields of two Tags. First, let me point out here that the "merging" of Tags is not always a true merge in the sense of combining two like items. In most instances, that will be the case. But this method allows the user to combine two unlike items such as say a Note Tag and say a Birth Tag. The important point here being that you are combining information that is of a duplicative nature. Using these two example Tags, the Note Tag may have some information in the Memo regarding the birth event and thus the Note Tag might be combined into the Birth Tag.
If there is no difference in the Principals, the Date, place, Memo, Source Citation, and Sentence fields then the two Tags are identical and one may be deleted. Some of the Tag fields may have some differences that the user sees and decides is of no importance. This may be in the Memo field where the wording is slightly different, but conveys the same information and/or the Sentence is re-arranged. Also the Source Citation may have a slightly different Citation Detail -- different wording, more inclusive page numbers, etc. Where there are differences, be sure that you retain the Tag will any added information unless you decide that loss of the added information is of no consequence (a rarity).
Usually the comparison of the two Tags will reveal differences in the Tags. The differences may be in any field and may range from completely different to only slightly different. For example, a Date in one Tag may have only the year and the other Tag might have a full Date. One Tag may have a County and the other not. The Memo may be different in some way. One may have a Source Citation that the other does not have.
Once the comparison is made, you need to decide which Tag to retain and the other would then be deleted. But deletion would not be done until you have made sure that deleting the duplicate Tag will not cause the loss of information. So open the Duplicate Tag, and for each field having more data than the "master" Tag (the one to be retained), copy that data and paste it in the master Tag. Do this for all fields. Often you may decide to just type the "missing" data into the master Tag. At other times, you may wish to highlight the data in the duplicate Tag, press Control-C to copy the data to the Windows clipboard, close the Tag Entry Screen, open the master Tag, click on the appropriate field, and press Control+V to paste the data from the clipboard to the field.
When all data has been copied to the master Tag then the duplicate Tag will no longer be needed and may be deleted. Make sure all Tag Entry Screens are closed, click on the duplicate Tag in the Person View and click on either the yellow dash icon button in the Toolbar or press the [Delete] key and answer [Yes] to the displayed question. Always read and consider this question as it can save you a lot of grief when you realize that you deleted the wrong Tag.
The copy/paste/delete method will be used mostly with event Tags, but may be needed to eliminate duplicate Relationship Tags as well. A duplicate Relationship Tag exists when you have a Primary parent (in the Father or Mother fields of the Name box of the Person View and a non-Primary parent Tag in the Tag box and the ID numbers in the two Tags are the same. Again you would review both Tags and if they are exactly the same then you should highlight the non-Primary Tag and delete it as above.
Similarly, the parent may have two child Tags that are the same. If that is the case, you can delete one. But, it is recommended that you do not delete an apparently duplicate child Tag from a parent. There is no way to discern in the parent's Person View which child Tag is a Primary Tag and which is non-Primary. Therefore only delete duplicate Relationship Tags from the Person View of the child.
Finally, when merging Tags for persons, consider how you want the data to appear in your project/data set and in reports. There may be times when some Tags may appear to be duplicative at first glance, but that one contains incorrect data either in whole or in part. You may want to retain the "bad" data marking it as incorrect for reports, with an "incorrect" surety value and/or with Exclusion or Sensitivity Markers so you can control how it may appear in reports. This "bad" data may be widely known in you family and you may want to describe how and why it is wrong. This would be so that people reading your report will know that you know about the data and have not missed it or ignored it.
|Other merge situations
We have discussed much of the hows and whys of merging and have mentioned a few situations where merging may not be desired. We have also talked about most records that users will want to merge. such as Flags of persons, Research Tasks, places, and DNA records. I cannot think of other things that a user might want to combine that don't fall into one of the categories above or into these just mentioned.
Flags cannot be merged by their very nature. They may have one setting and that is it. When two persons are merged, the merged into person will retain its Flag settings and the merging (or the deleted) person's Flags will be dropped. Thus, it behooves the user to review the Flags and note the differences (if any). Then the user may decide whether a Flag in the merged person needs to be changed in any way. Mostly, you will not need to be concerned, but a wrong setting on a Flag can cause a report to not include someone. For example, person A may be have its LIVING Flag set as Y and person B may be set to N. If person B is merged into person A then the LIVING Flag set to Y even if Death Tag of person B is copied over to the merges person A.
Similarly, you may have a Custom Tag three possible settings. Two settings might indicate two different family lines and the third setting may indicate that the person is a member of both family lines. It may be that persons A and B each have the opposite family line setting. When the merge occurs, one family line setting may be "lost" and you would want to correct that by changing the Flag setting to the combined value.
In most Custom Flag cases, you would not really lose data and you can recover a lot of the "lost" settings by running a List of People or List of Events report (or reports). But that takes extra work you may not wish to do. Then there are the exceptions where you have made a Flag setting and that is the only place in the data it is recorded (say that a person was known to be unmarried or had no issue). To minimize the los of data of any kind, it is recommended that you review all Flags for the two persons before the merge.
No provision is made to merge Research Tasks. This would be a rare case where you may wish to do this, but life (or is is Murphy's Law) ensures there may be times. In those cases, you will need to do the merging manually as in the copy/paste/delete method.
The same would apply to the DNA Test records in the DNA Log. Any merging here would need to be done manually.
In the case of places, this is a different thing altogether from
the other records above, but due to the similarity of the situation
we will discuss it quickly here. Keep in mind that when the
Master Place List (MPL) shows two places that are or appear to be
the same, you may or may not have duplicate places. First,
keep in mind that the Master Place List that you see is not the
actual place database in your project. The MPL is closer to an
index of the places database and usually indexes are created once
and then updated as necessary. Often indexes can get mixed up
for various reasons and then they need to be re-created. In
the case of the MPL, the mix-up can come when you edit a place such
One thing to remember here is that Optimize will not merge/delete
place records which are not exactly the same or where a place
record has an entry in one or more of the following fields:
|Finally, be sure and do a Backup before you do any
merging. As noted above, if you inadvertently delete the wrong
Tag, merge the wrong way, or whatever then the backups can really
help save the day.
For another view of this same topic with more detail, see Terry Reigel's article on Merging Projects and Data Sets on his web site.
Hope this helps!!
Return to the TMG Tips Tutorial Page