* FH-RM-Ancestry Sync error

[gapperly]

This issue relates to the Family Historian - RootsMagic - Ancestry Sync plugin as described in the Knowledge Base article Synchronizing Your Tree With Ancestry to Exploit Hints.

The plugin function 'Compare' returns the FH error "Cannot create local copy of RootsMagic file for processing!"

I have used this plugin successfully on my W10 desktop several times. I recently upgraded FH to v7.0.15.

I have no idea what would cause this type of error so I don't know how to proceed.

Any advice would be greatly appreciated.

[Mark1834]

Thanks for reporting that. It's my plugin, and I get the same error with FH 7.0.15.

The plugin creates a temporary copy of your RootsMagic database as a workaround to deal with limitations in character encoding in the plugin code library, and the error message arises as it is not able to create this copy for some reason.

I will investigate over the weekend and report back.

[Mark1834]

It's a bug in FH 7.0.15.

The copyFile function in the fhFileUtils module has been changed between FH 7.0.11 and Fh 7.0.15, and the new version doesn't work. If you try to copy a file, it fails and returns a 'Destination folder not found' error message irrespective of whether the destination folder exists or not.

Unfortunately, that breaks every plugin that uses the function. It can be repaired by overwriting the new version of the fhFileUtils.fh_lua file (1.4) with a backup copy of the old version (1.3), but that requires admin access to your PC and is not something every user will be comfortable doing.

It needs reporting to CP, but I'll hold off at the moment as it is Jane and Helen that maintain fhFileUtils, so I suspect one of them will comment over the weekend.

[Mark1834]

This hasn’t been forgotten - an updated fhFileUtils has been developed and tested, and should be included in the next FH maintenance update.

[Mark1834]

Even when FH is updated to replace the faulty version of fhFileUtils, the plugin will need updating, as the new version does not overwrite existing files by default. This means that when the current plugin is run in the next version of FH, the Update option will not work correctly as the updates made to the RM database by the plugin will not be saved to disk. The effect of this is to duplicate old and new versions of all updated events.

This updated plugin overcomes that problem by using a local copy function independent of fhFileUtils, and runs in all versions of FH from 7.0.8 onwards, including the next update.

It is a required update for all users of the plugin, and the KB article describing the process has been updated to point to this new version. All previous versions of the plugin have been deleted from the forum.

[cschroeder]

Hello,

I have a problem with a large family tree with the current version. The following error is displayed:

"An error has occurred - plugin failed to complete [string xxx] bad argument #1 ti 'MoveTo' (fh.PITEM expected, got nil)

Is there an easy way to find out which record the error occurs on?

[Mark1834]

Sorry about that Carsten. That part of the plugin script is checking children that are attached to more than one family, where those families have only a single parent identified. It's clearly not a very common situation, but the RM file merge does not handle multiple one-parent families very well.

An example is where a woman has two children by different unknown partners, and the RM file merge can mix up the families so both children appear to be attached to both unknown partners.

I will see if I can reproduce that in a small test database later this evening, but does that give you a clue as to which record may be causing it?

[Mark1834]

One more diagnostic test - if you are happy to edit the plugin script (Tools > Plugins > More>> > Edit...), please edit line 479 of the plugin to change

Code: Select all

CheckOneParentFamilies(database, tblFHI, tblRMI, tblUID, tblFHF, tblRMF)

into

Code: Select all

-- CheckOneParentFamilies(database, tblFHI, tblRMI, tblUID, tblFHF, tblRMF)

By putting two dashes in front of the line, you stop it being called, so the parent check does not run. There will be parent or family differences recorded in the Research Note output, but one of those is likely to be the offending record that the plugin is not handling correctly.

[cschroeder]

Yes, thanks, after deleting the displayed data records everything is working again

[Mark1834]

If you don’t want to delete records, a workaround is to use dummy placeholders for missing parents so the RM merge works smoothly.

The plugin ought to deal with these records, so I’m happy to investigate if you can describe the relationships.

[cschroeder]

no, deleting the records is no problem at all...

I am glad that you created the possibility to exchange data with Rootsmagic...

[harold]

I find this plug-in interesting. I played around with it a bit in the spring and thought it had a lot of promise. I let it slide over the summer but recently decided to try it again.

I am using the latest version (0.3.3) to work with my FH 7.0.18 installation.

Curiously, when I try to run the initial export of the FH data it seems to never finish. My project is not super large. It has around 5300 individuals, 1850 family records, and 11,000 facts. I use templated sources. I also use a few witnesses and witness links ( I mention them because I may have added them since the last time I used this plugin).

I don't recall the export taking very long in the past. Should it take a long time to run or am I just being impatient?

Harold

[Mark1834]

That does sound odd, Harold. The initial GEDCOM export should be very quick, no more than a second or two to a typical hard disk. When you say “never finish”, do you mean that it just hangs, so you have to force FH to close, or runs to completion, just slowly?

[harold]

It hangs and I have to force FH to close. The task manager indicates there is a lot of CPU activity but no disk activity and memory usage seems to remain static, so I would tend to believe it is stuck in some type of loop.

[harold]

After a private email exchange with Mark it seems to be the individuals flagged as "Living" which were causing the problem. I did a bit more digging and realised I had selected the option to include Persons marked as "Living" in the export. Once I de-select that option the export works fine.

[jelv]

Odd! I'm using it with living individuals included without any issue.

I'd suggest it's not including living that is the issue, but something specific on one of the living individuals

[Mark1834]

Yes, the root cause is that the current version does not handle private facts correctly.

Harold kindly shared a copy of his project to enable diagnosis, and is currently testing a new update. I’ll post it here in a couple of days if no issues are identified.

[jelv]

Will you be including the modification I suggested here?

viewtopic.php?p=129088#p129088

[Mark1834]

Not yet, no. I haven’t had time to look in detail how RM treats the time element of the update stamp. The RM developers clearly thought it important enough to introduce a new set of table fields, but RM8 does not appear to use it consistently or display it anywhere in the UI.

Early versions of the plugin didn’t update the RM record stamp at all, but TreeShare still worked in the same way. Until we have a better understanding of the consequences of changing it, I think it is safer to stick with date only. A time of 00:00 is always valid, and there is a risk (albeit small) of something going wrong in RM if it sees a time it is not expecting.

[jelv]

OK. I'll apply the change to the new version myself before I use it when you let it loose.

I've done a number of syncs to two different RM databases with that change without seeing any consequences.

[Mark1834]

Probably worth considering the question from both directions - are there any harmful consequences and is there a discernible benefit to the change, either in how data are displayed in RM or in TreeSync operation?

[Mark1834]

Updated plugin attached. The following changes have been made since version 0.3.3:

• Processing of facts marked as "Private" corrected.
• Facts marked as "Rejected" are excluded from the GEDCOM export.
• Improved processing of date phrases. FH stores date phrases in the GEDCOM file in parentheses, but a plugin returns the value in double quotes, the same format as used in the Focus Window and Property Box. RM neither requires nor recognises either quotation marks or parentheses, so treats them as part of the phrase when imported via GEDCOM. The plugin now ignores these differences in formatting, so only flags a difference if the actual phrase text differs (note for Mike - I don't think the Export GEDCOM plugin removes the parentheses when RM is defined as the target - that might be worth including in a future update).
• Various minor cosmetic improvements in file selection and Research Note formatting.
• My working copy also includes a new feature whereby FH manages the TreeShare "only show changed people" checkbox. This will make it easier to work through the Ancestry updates, as the list of individuals to update will be presented directly in RM rather than having to cross-reference back to FH. I'm still testing it to make sure it works as intended, but it should be in the next update.

[gapperly]

Hi Mark, The previous post refers to the plugin attached but it doesn't appear to be there.

[jelv]

That's because the latest version is in the plugin store: https://pluginstore.family-historian.co ... ronization

[gapperly]

Thanks John, the first attempt to use the new plugin Ancestry Synchronization (Version 1.0) failed. The "Compare" process returns the following error.

[string "C:\ProgramData\Calico Pie\Family Historian\Pl..."]:897: attempt to index a nil value (field '?'). No changes have been made to data records.

I'm running FH v7.0.18 under Windows 11. Any ideas how to resolve this would be appreciated.