I'm glad to see this error is not on my end. I've been putting in addresses all week, and when I went to check out the map feature today (I think it's the first time I've tried to use it) I got a script error. Actually, I got 3 identical script errors, and then the blank page. I'm just glad it didn't freeze the program because my dumb self doesn't remember when I saved last... But here's the question I have. This post says that the bug would be fixed in version 6. As far as I can tell, I have version 6. I double check, and it says I have the most recent version. So what's the deal? Is this still a bug? Has it been fixed yet?
I haven't had any real complaints with the MyHeritage site, or with the FTB, but if I could make one request, I would love to see a list of changes, added or updated features, and known bugs, features that are currently being worked on, etc. Most of the programs that I use have this somewhere on their webpage, and I was very surprised that I couldn’t find one on MyHeritage…
Well, yes I think it’s practical to use RegCure to update software programs. Also, make sure to close all other applications while you’re at the process; and try to complete it fast before any Internet interruption occurs.
I experienced this issue a month ago or so where the "Merge" button on the SmartResearch screen is no longer accessable. Last time I saw this thread in the forum and installed ver 1189 version of FTB. This seemed to get rid of the problem.
Two nights ago-- it happened again. This time I found a newer version on the myheritage site-- rev 1198.
I installed this version but there was no remedy of the dimmed merge button.
Also the SmartMatching seems to be somewhat flakey-- on the FTB PC side it shows a match with multiple hits, and then when I select the match it says there are no matches available. This happens on many of the matches denoted but not all.
When this started happening again-- I had just crossed the 5000 person in my tree. I noticed that there was some message posts about a limit of 5000 matches due to a security limit. This seems a little odd that you would limit users to an arbitrary number when we have to pay extra to get the feature in the Premium package. A much more smart limit would be to have a date range on the limit so that a user can not match a large number within say a week or something similar.
Any assistance you can provide would be greatly appreciated-- sinice this issue has severly limited my use of the system.
The most updated version of the software is version 1198 which you can download from above link.
The version includes the merge limit update and few other minor bug fixes.
You get the message that you have the latest version because version 1198 includes only small fixes that do not effect all users. There is no need to send all users a message to download and install again as the merge limit effects only small percentage of our users.
Anyway, version 1198 has a limit of 50,000 merges. This limit is very high and I am sure will not intrefer with your work.
A part of my family tree is maintained by another person, who delivers record updates through a Gedcom that covers that entire subtree (he uses another genealogy program). How do I avoid that updated and unchanged records of that subtree appear twice in my assembled FTB tree when I import that Gedcom? It seems Gedcom import just adds records and does not replace records for existing people. Should I first manually remove such people from FTB before the import?
If I then publicise the new data, will that restart the smart matches mechanism for these persons over again? I can imagine the administrators from other sites may be upset when they are asked to review the information for such persons repeatedly.
The method you propose is impracticle in my case: the other person maintains his family tree with another tool (good old PAF). Regularly I receive a Gedcom file which I merge as a subtree in my tree which I then publicise. As an example, last time I received a Gedcom file with 3 additional persons, 14 changed records (small additions or changes) and 350 unchanged records. You see, if I merge everything and then manually remove the duplicates, this becomes a nightmare.
Would the following work: I maintain 2 FTB projects: one in which I maintain my own dataonly (FTB1). The other one(FTB2) is completely emptied each time I want to publicise. I the import in FTB2 the content of FTB1 and the newly received Gedcom file. I then publicise the merged project.
I suppose this should work, but I fear that the Smart Matches tool on your server will consider each record as a new one (it was never flagged as a "duplicate") and would recompare my data with the other family trees and signal all matches again. And this every time I do a publish. No doubt I would get angry reactions.
This all becomes very technical. How does your server identify each person? If it is e.g. by name birth date/place, it should not be a problem. If it is by some internal reference number,it (thinks it) sees a new person.
However, the point is that the subtree (including changes, additons and unchanged records) will still regularly be delivered in gedcom format. I cannot convince the other editor to switch to yet another editing environment. So I would use the two-FTB approach, described earlier, resulting in a re-publish of the entire tree every one or two months.
As explained before, I am very worried that the Smart Matches mechanism might swamp other family tree publishers with "new" (but in reality identical) matches every time I re-publish the tree. I suppose every person would possibly be considered as a new one each time. Could you elaborate on that, please?
You can have different Smart Matches settings for each of your online trees - if you follow the instructions I have sent you, you can prevent receiving the same matches for your second tree by disabling Smart Matches for the second tree alone.
If you enable Smart Matching for both trees, other site managers will indeed receive matches for both of the trees, but you will not receive matches to other trees you manage.
Seems we don't understand each other. As described earlier, I want to merge two trees (my own subtree as FTB1 import of Gedcom into a prevously cleanedFTB2) on my local machine and publish online the merged result, hence only one tree is published at any time.
My question is: will Smart Matches send around new match reports to other family tree administrators for all persons in the published tree (the published version of FTB2) or only for the newly added persons (compared to the previously published version - the changes may originate from either FTB1 or from the Gedcom input). This all depends on how person lists are maintained within your server and is a technical design matter.
Obviously in a family tree there are many people with the same name. A person added to the tree should trigger Smart Matches, even if he/she has an already used name. How does the tool differentiate? If done by e.g. birth date, that would solve the issue. I hope it is not by RIN number, since that one is reallocated each time for every person by FTB in my scenario.
I hope this thread was also useful for other administrators, since many work in mixed environments.
Please note, that the Smart Matching engine comdines all the entered inforamtion about each individual in your tree project (name, birth dates, relatives) in order to search for suitable matches for that individual.
My charts don't have last names on them. I'm running family tree builder 220.127.116.118. I've run 'check for updates' and it says this is most current. When I first open a chart for first time in a given project, it defaults to 'stylish' design - names and pics look fine. I don't want the photo's so I switch to 'traditional'. At this point names and pics still look fine. I then pick the 'never' option on photo size and photo/placeholders disappear but so do last names of everyone. I switch to 'only if exists' and last names are there if pic is, but no last name if not.
Is this a bug?
I've attached screen shots of 'never' and 'always' showing how last name disappears when no picture.