ok, 4 month more of a none wworking programme/feature. I just want it to work. I can't be the only one with this problem but it seems your not intrested in fixing it
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.
Will do. I downloaded the other recommended version (I want to say 1183?) to solve this last night, but have not installed it. A couple questions about this version...
My software is saying I have the latest version, is there a glitch in it? Concerned as I'm having another problem that's being addressed as well...
Does this version change anything else or just the merge issue?
Will there still be a limit on merges with this version?
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.
Well- for the moment the system has started to work again- late Saturday night. Not sure why-- but I have been able to continue to use the merge button yesterday.
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.
After merging two trees in Family Tree Builder, what you can do is to use the check for duplicates feature (tools > Check for duplicates), to locate the duplicates in your tree.
Once you have found them, please use the following directions to merge duplicates in Family Tree Builder:
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.
If you publish the merged project with the same name as the project in your family site, you will not receive the Smart Matches you have already confirmed / rejected for this tree in your site;
You will receive Smart Matches for the new individuals / the ones you edited.
If you publish the merged project with a different name, the Smart Matches search will work for all the individuals in the project, just like for a new project.
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.
