* Ancestry Synchronization Error

[Fred987]

After I export, then import into RM then close that then run the "compare project with linked RM file" the box with checking opens and after it closes a few seconds later the rotating circle appears for a while then I get the error shown. This is only on 1 database, it does complete properly on a 2nd one I tried so I deleted the original export and RM file and tried the failing Database again with the same results. I assume this means its not updating the living in RM with this error? is there something I can try?

[tatewise]

Does any of your Individuals have a Surname that contains symbols such as ( , ) , - , * , % , etc?

Note to Mark:
The use of gsub(...) is risky unless you protect the 'magic pattern symbols' in the pattern and % symbols in the replacement.
e.g.

Code: Select all

		local Name = fhGetItemText(p, '~.NAME')
		local Surname = fhGetItemText(p, '~.NAME:SURNAME')
		local SurnameUC = Surname:upper()
		Surname = Surname:gsub("(%W)","%%%1")
		SurnameUC = SurnameUC:gsub("%%","%%%%")
		local ModName, n = Name:gsub(Surname, SurnameUC)

Without that adjustment, any 'magic symbols' in the Surname will inhibit the replacement &/or the gsub will fail.

BTW: It seems your script does not handle Unicode UTF-8 accented letters, etc.

[Fred987]

Thank you! that was it.. LOTS of searching I found a few hyphenated names and a few O'Keefs and a question mark or 2.. Its working now !! Thanks again

[tatewise]

IMO Mark should update the plugin to cope with those symbols rather than users having to edit their Projects.

[Mark1834]

IMO Mark should update the plugin to cope with those symbols rather than users having to edit their Projects.

Well done, Mike - I think that is the most pointless post I've seen for a long time. When users find bugs, authors update their scripts to correct them - why did you think I wouldn't bother and expect users to change their data...?

It's a curious one. There are actually two separate issues.

The first is dealing with punctuation characters in names. My test dataset includes hyphenated names, and while the case conversion is not correct, the plugin does not generate any errors. It may be particular combinations of characters that cause problems.

How characters are capitalised in international alphabets is a separate issue. For this plugin, it is largely a cosmetic issue, as it only affects the presentation of names in the output report. The core plugin functions work correctly with all names, irrespective of any punctuation characters or international character sets.

There is actually a very easy workaround until the store version is updated. Open the plugin options, and select Display Family Historian Individuals as Links. That bypasses the problematic code altogether and uses the built-in FH records display. I wouldn't recommend changing names, even temporarily pending a fix, as they will need to be changed back in all three apps, FH, RM and Ancestry once the update is available.

[tatewise]

IMO Mark should update the plugin to cope with those symbols rather than users having to edit their Projects.

Well done, Mike - I think that is the most pointless post I've seen for a long time. When users find bugs, authors update their scripts to correct them - why did you think I wouldn't bother and expect users to change their data...?

Sorry, my comment was perhaps badly worded.
It was aimed more at Fred than you because he had already edited his Project rather than waiting for a fix.

I cannot comment on the plugin details except to say I have learnt from bitter experience that it is necessary to 'hide' the 'magic symbols' in both the pattern and replacement when using gsub(...) and related functions.

Perhaps I'll just remain silent in future.

[Mark1834]

No problem, Mike. Thanks for the clarification.

It is perhaps surprising that gsub(...) doesn't have a "literal" parameter similar to that in find(...), but we have to deal with the language as it is, not as we would like it to be.

I must admit, I tend to steer away from the more complex application of patterns in my plugins, as I find them rather opaque. For me, the most important property of any published plugin is transparency to other authors, so it can be supported and adapted when the original author stops doing so (as will happen eventually to all plugins, assuming FH doesn't stop working first!).

In this case, I have an alternative version that uses find(...) with the literal parameter set to locate the surname. It needs a simple decision tree to cope with all possible formats (given or surname missing, western or eastern order, even malformed names that include prefix and/or suffix in the main name), but it's easy to understand and debug, even if it is less elegant or resource efficient for the edge case of extremely large projects.