Search for content in message boards

Can't Sync? Try This.

Replies: 7

Can't Sync? Try This.

Posted: 1388948166000
Classification: Query
Edited: 1388971226000
If your TreeSync fails, you *may* be able to fix it yourself by following the steps I describe below.

Each time Family Tree Maker (FTM) attempts to synchronize with (AMT = Ancestry Member Tree), various hidden files are created that can be used in some cases to manually repair linked trees that will no longer synchronize. On my system, these files can be found in the following location:


Your location will be different depending on your user name (in Windows mine is “Marco”) and operating system (I know the path [i.e., location on the computer] is the same in Windows Vista and Windows 7). Also, note that the \AppData\ is one of those hidden system directories that you cannot see by default, so you'll need to go into your viewing options in Windows Explorer to display them if you haven't already done so.

If you can’t find this folder, it *could* be that it was deleted. In fact, that was my problem before I attempted to fix my broken sync manually. Yes, I had a \Temp\ folder at this location, but I couldn’t find the \FTM\ folder inside that. I later discovered that Norton 360 on my system was set to delete unnecessary files my temp folder, which apparently includes any unnecessary directories like this. (Also note that the SyncErrorReporter.exe will not function properly without this directory *and* its contents.) For those of you lacking this folder, this means that you will not have any files to investigate after your sync breaks. To fix this, just create the \FTM\ folder inside the \Temp\ folder, and (attempt to) run the sync again. The files you will use to repair your sync can be then found in that folder.

To make this manual repair process easier, I recommend saving a copy of your “TreeSync Change Log” when prompted to do so during the sync process. You only have a 60-second window in which to do so. Yes, this means constantly checking your computer during what can often be a sync process that takes 1.5-2 hrs, depending on the size of your tree and where you made the changes.

(If you didn’t save this log, don’t worry: just (attempt to) sync again so that you can save the file when prompted. If you’re wondering what I do, I always export to PDF and tack on the date and time to the end of the file name.)

With your “TreeSync Change Log” and your \AppData\Local\Temp\FTM\ folder, you’re ready to start the manual repair process. When your TreeSync fails, the reason will be described in a log file in the …\AppData\Local\Temp\FTM\ folder. (Note that this is a *different* log file than the “TreeSync Change Log” to which I referred above.) The name of the log file where this reason is described will look something like this:

032f345d-c3d4-4235-ab75-c2fd3ac5ac0b_IncrementalDownload_Log_01-03-2014 172329.xml

The first part is always a unique alphanumeric sequence that signifies a specific tree in FTM. The trailing part indicates the date and time when the sync started. There will be other files located along side the log file in the \FTM\ directory. If you have a lot of them, just sort by date-last-modified, and it will be the most recent file.

As you can see by the file’s extension, this is an XML (Extensible Markup Language) file. You can open this type of file in any text editor, word processor, web browser, XML viewer and a variety of other supporting applications. Some of these programs are better for viewing than others. A web browser like Chrome or an XML viewer, for example, will format (i.e., lay out or present) the file’s contents to make it easier to read. Unfortunately, whoever did the programming for the log file forgot to include a snippet of text at the end of the file that enable programs like this to format the text.

That’s not a problem. You can fix it yourself in a text editor, and then open it in a program that can format it. Here’s what I do:
1) I open the log file in Notepad.exe, a program comes with all versions of Windows
2) I scroll to the bottom of the file’s contents, insert the cursor, and type “/SyncLog”, only enclose it by less-than and greater-than symbols, and don't include the quotation marks. The message board will not allow me to include the exact text with these symbols, so that's why I'm explaining it.
3) I save and then close the file.
4) I open it in my web browser, Chrome, which reads all the tags and figures out a simple way to present the file’s contents to me. Voila. Much easier to read.

The first thing that I look for in the log file is the explanation for the failure. When formatted by the viewing application, this is fairly easy to find. The explanation usually comes in two parts, located in the latter half of the log file. The first explanation is enclosed by "Exception" and "/Exception" tags (the tags are demarcated by less-than and greater-than symbols). The second explanation is enclosed by "InnerException" and "/InnerException" tags (again demarcated by less-than and greater-than symbols). The messages are sometimes redundant, and most of the information is only relevant to the programmers, because it helps them to identify the instructions that were executed that resulted in the error. In spite of the esoteric explanation, there is usually something that we can glean from what’s reported.

Consider the reason reported for my latest sync failure: “Abort due to constraint violation column[;] FtmId is not unique”. I see this error repeatedly. It means that the table to which FTM wants to write data contains some rules that help maintain the data’s integrity, a typical feature of relational databases. In this particular case, the database identifier from Family Tree Maker is already in that table, and executing this action would create a duplicate, which isn't allowed.

From a data management perspective, preventing duplicates is a good thing. From the perspective of a customer using software that wasn’t adequately tested, that’s a frustrating thing. Whoever wrote the TreeSync code didn't prepare for this eventuality, so the sync fails. We can't change the sync code, of course, but we can alter the information in our trees that is causing this problem. Other users have eliminated this data and successfully synchronized after doing so. You may be able to as well.

Now, the data that's causing this problem is identified above the Exception statements in the log. In the case of this particular error of mine, information about the data causing this is enclosed by three different Message tags. If you’re not viewing this XML file in a program that formats it (or you didn’t edit it as I described), then you can typically find these messages by searching for the following strings: “ftmid”, “amtid”, and “clientid”.

Enclosed in these Message tags, information about the point of failure is conveyed:

(#1) Person: id: 6393; amtId: 1886533302; clientId: ; operationType: Changed
(#2) Citation: id: 9873; amtId: 5231684503; clientId: 9873_6393; operationType: New
(#3) Reference: id: ; amtId: 1886533302_5231684503_; clientId: 9873_6393_39782; operationType: New

The first message tells us the person in the tree to whom the troublesome data is connected. In this example, the person is known to FTM as “6393” and to AMT as “1886533302”. These numbers are very helpful, because we can use them to find the person in FTM and AMT.

How do I look up someone in FTM using the ID number I see in my log file?
1. In FTM, click on the edit menu on the main toolbar, and then select “Find Invdividual…”
2. A dialogue window will appear on your screen. When it does, change the combobox (i.e., the pull-down control) from “Name” to “Person ID”.
3. Copy and paste (or type) the number that follows “id:” (or sometimes “ftmId:”) from the log file into the textbox (i.e., the place where you can type) to the right of the combobox. In my case, it’s “6393”.
4. Click the “Find” button to the right of the textbox.
5. FTM may take a moment to search, then it will display one or more results in the textbox control below. If you have more than one result, look for the entry in the Person ID column that exactly matches the number from the log file, i.e., “6393”, not “16393”.

How do I look up someone on AMT using the ID number I see in my log file?
1. Go to your AMT and view the profile page for anyone. It doesn’t matter who it is.
2. Look at the address bar in your web browser. You will see something like where X = your tree number and Y = the ID of the person you’re looking at.
3. Change the number represented by Y above to the amtId reported in the first message of your log file. In my case, that’s “1886533302”.
4. Hit the “Enter” key on your keyboard to load the new address in your web browser. If cannot find the person, add a dash before the number and try again. For example, change to If it still can’t find the person, double check that you’re copying the correct and complete number from the log file. If you’re still having problems, post the pertinent information from your log file here, and I will help you if I can.

Now I’m ready to glean information from the second message. I’ll repeat it here:
Citation: id: 9873; amtId: 5231684503; clientId: 9873_6393; operationType: New

The “id” (yours might be called “ftmId”) of “9873” refers to the unique database identifier in Family Tree Maker for this citation. FTM doesn’t expose these numbers to us from its database, so I’ll just note that the “clientId” of “9873_6393” listed here also includes “9873”, and if you recall from above, “6383” was the FTM identifier for the person in question, hence (Citation ID)_(Person ID).

The “amtId” of “5231684503” is obviously the equivalent database identifier for this citation at Luckily, we can use this number to access the citation by writing it into the URL in the address bar of our browser.

How do I look up a citation for someone on AMT?
1. Visit the profile page for the person in question. (If you’re following along with me, and recreating my steps on your end, you should already be there.)
2. Place your cursor at the end of the URL in the address bar and type “/citation/” followed by the number included in your log file for the amtId. In my case, that’s “5231684503”. (Do not include quotation marks in what you type.) In other words, I change to
3. Hit the enter key on your keyboard to load the new URL. The page that loads will display the source citation as listed in the “Source Citation” tab of the “Facts and Sources” tab for this person. In my case, I note that this is a record from the Social Security Death Index for this person. (This will probably not be accessible to you as a working URL, because to repair my sync I intend to delete this citation.)

Now it’s time to look at the third message:
Reference: id: ; amtId: 1886533302_5231684503_; clientId: 9873_6393_39782; operationType: New

I’m not sure what to make out of this “Reference” message. Logically, it would make sense that this is a reference to the fact to which the citation is connected. I note that I do not have an “id” from what I would expect to be the FTM database here, and I’m not sure what to make of its absence. Perhaps that’s part of my problem here, perhaps it wasn’t included from this message by a programming error, or perhaps it wasn’t included because it doesn’t apply. Even if I could see it, because FTM doesn’t expose these numbers to me, it probably wouldn’t do me any good anyway.

We can make some sense out of the “amtId” of “1886533302_5231684503_” by using information from the previous messages. We know that “1886533302” is the Person ID in my AMT for this person and that “5231684503” is the Citation ID at AMT. I note that this number is followed by an underscore with nothing after it. I would have expected to see a Fact ID number here, but this particular citation of mine at AMT is not associated with any facts, so that would perhaps explain why this lacks a third sequence.

(If you have a third sequence of numbers, you can probably look it up at your tree by altering the URL for the profile page of the person in question by changing, e.g., to where 21068852037 is the third sequence of numbers listed here.)

We can also make some sense out of the “clientId” of “9873_6393_39782”. This comes from FTM. We learned in previous messages that “9873” was the Citation ID in FTM for this person, and we learned that “6393” was the Person ID in FTM for this person. Still operating under the assumption that this third message deals with the fact connected to this person and citation that is causing a problem, I surmise that the third sequence of numbers, “39782”, i.e., that follows the second underscore, is the Fact ID in FTM’s database. (I can’t verify that, of course, because FTM’s database isn’t exposed to me.)

Up to this point in my discussion I have ignored the final component of the messages I’ve listed here in this posting. That’s the “operationType”. In the first message (which identified the person) it was “changed”. In the second message (which identified the citation) it was “new”. In the third message (which presumably identifies the fact) it was “new”.

This echoes information listed in the “TreeSync Change Log” that I recommended you save. When I search that log for this person’s preferred name fact I found the following entries for him that involve the SSDI. The following information is listed on the side of changes from FTM-to-AMT:
Donald "Don" James "Stollie" STOLL Changed
Fact: Birth - 10 Oct 1930 New
Citation: Social Security Administration, Social Security Death I... New
Fact: Death - 15 Nov 2003 New
Citation: Social Security Administration, Social Security Death I... New
Fact: Name Changed
Citation: Social Security Administration, Social Security Death I... New

So, it says the person was changed by (1) adding a new birth fact with a new citation based on SSDI, (2) adding a new death fact with a new citation based on the SSDI, and (3) changing an existing name fact by adding a new citation based on the SSDI. Based on this information, I think we can eliminate (3) as the point of failure of the sync, because in it involves an existing fact, not a new fact as described by the “operationType”.

That suggests that either this new birth or death fact is causing the sync to fail. I don’t have enough information to know which of the two is the culprit. If it didn’t take 1.5-2 hrs to attempt a sync, I would might delete one at a time and try again. Given the extraordinary time required, however, I’m going to delete all traces of the SSDI both in FTM and on my AMT just to be sure that I've eliminated what's causing the sync to fail. I’m also making a note of these activities for future reference. If I’m able to get the sync working again—or if I have to redownload my tree from AMT—I’ll add the SSDI record at that time. My list of other deletions and changes will come in handy when I finally have working linked tre again.

Once this information is deleted, I will attempt to sync again. Although my tree still won't sync, each time it fails I get a different point of failure, so I assume that after I fix all of the problems, I will be able to sync again. I say this because at least three others have reported that after deleting the facts and/or citations listed in their log files, they've been able to sync again.

I hope this helps others fix their trees that won't sync. Good luck!

(Special thanks to user BertaPep who first called our attention to this in
SubjectAuthorDate Posted
MarcoScavo 1388948166000 
rdn2137 1389030010000 
MarcoScavo 1389035824000 
silverfox3280 1389041128000 
jamclo 1389050386000 
David Abernat... 1389058379000 
Roland Stuart 1389068796000 
RobertBrinsfi... 1389111754000 
per page

Find a board about a specific topic