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.
 

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 similar.
 

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.

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.

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 as:
          Carmargo, Montgomery County, Kentucky
to correct the misspelling to:
          Camargo, Montgomery County, Kentucky
In such a case, you will note that the correction is made and that is it.  But as more and more places are entered in a data set, you may already note that the place is also in the MPL correctly.  Now you have two places that are the same.  In most cases, you would exit the MPL, and choose to Optimize the MPL (File=>Maintenance=>Optimize from the Main Menu).  Optimizing will then effectively re-create the MPL after eliminating the duplicate records.

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:
            Short Place, Start Year, End Year, or Comment.
As an example of a place that is not exactly the same, note that " Camargo" is not the same as "Camargo".  Nor are either the same as "Camargo " or "Camargo-".  This last is a lot easier to see that where a space added at the beginning or ending or in the middle of a field.  In cases such as this, you may need to just delete the field entry(s) of a place record and re-type them within the MPL.  Since you may not know which of two (or more) duplicate place records is the bad entry, you may need to delete the field and re-type them and/or copy/paste one record to all of the duplicates. 

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!!