* FH7 RootsMagic9 database direct import crashes program

[Gary_G]

I did three successful project database imports from RM9 to the latest FH7 and had no issues at all. Then I tried a fourth RM9 project, having run all the RM9 Tools to clean, compress and validate the database. I imported it with the exact same settings as the previous three instances, but this one crashed FH7 on the last pass (step 9) of the import. It left behind an empty project GEDCOM and absolutely no log file to show what had gone wrong. Thankfully all my pre-existing projects appear OK.

I've run an exported GECOM through FTanalyzer and the errors where nothing serious; just one or two duplicate facts.

Has anyone seen this before and has some suggestions? Does FH7 have a debug mode in which I can get some form of a detailed log to see where the import failed?

If not; I'll drop CP a line. In fact; I may do that anyway, since a complete crash should not happen.

[tatewise]

If you check the Help page for the Choose Import File dialogue it says:

Family Historian can import directly from the following family tree files:
...
Roots Magic database files (all versions up to and including version 8).

So it is not designed to cope with any features added in Roots Magic 9.
However, I would expect FH to check the version and perhaps inhibit the import.

So, it is definitely a question for CP to resolve.

[Mark1834]

RM9 is only an incremental update from RM8, with the same basic underlying database structure. The most significant change is probably the added support for non-family associations between individuals. These are manged in two new database tables, one that defines association roles (employer, friend, slave owner, etc) and the other the detailed links between individuals.

A quick check suggests that the association feature is ignored when importing an RM9 file, so it's not clear whether the import has been modified since RM9 was introduced, or it has always been programmed to ignore features it cannot process. CP will probably ask for a copy of your RM9 file to see if they can duplicate the issue and determine the root cause. It will also be a timely prod for them to update their documentation to clarify how FH processes RM9 files.

[Gary_G]

Thanks, Mike and Mark.

I've never used associations in RM9 and the same goes for most of the other RM9-only features. I've really had no use for them. As all other RM9 imports have been flawless, I doubt that this feature was the cause.

FH7 seems pretty robust. RM9, on the other hand, has given me a lot of trouble. It has, on several occasions, passed corrupted databases through its validation tools without flagging anything. That's why; I was hoping that the FH7 import might have a debug feature that would tell me a bit more about what caused the crash.

As was mentioned; CP has asked for a copy of my database. I'm always a little hesitant about such requests, since there can be personal info embedded. That said; I will likely send it and trust that they will use is only for the purpose provided.

I should note that RM9 has the quirky ability to resolve internal database issues by drag-and-dropping the old data to a blank database. Somehow, in the re-import, it straightens things out. I'm going to give that a try before sending anything to CP, but it does require a bit of work afterwards to clean up the sources. Thought I'd mention this as it may help someone else.

[Gary_G]

I tried the database drag-and-drop trick with the RM9 database. It picked up some minor issues, but FH7 still crashed on import.

I've had a hard look at the content of my RM9 citations for the subject British/Scottish line (~300 people). They are pretty dated, as they are some of my earliest work. So; I'm likely better to strip the citations and import the bare tree. The actual field content could be the issue and would definitely need to be fixed up once imported, anyway. As I have saved all the necessary data in external "sidecar files" to my images, redoing them using AS will likely make this a straightforward task. It will also give me a chance to clean up my file naming at the same time.

[tatewise]

Nevertheless, CP would no doubt like the original RM9 file to recreate and fix the problem.

[Gary_G]

I've already offered to send it, Mike.

---

By the way; if one is starting out with just the tree itself and no facts, would it be best to put in the census first or the BMD facts? I understand that AS is "smart" in filling in some fields and may work better with certain facts entered first.

[Gary_G]

CP has said they will address the crashing issue. It was apparently caused by a single malformed template definition in RM9. Despite running all the RM9 diagnostics, it wasn't picked up prior to import into FH7.

[Mark1834]

Good that CP have responded quickly, but it may not be an RM error. They don’t publish details of the internal database structure (even though it’s easy to reverse-engineer, even for amateur hobbyists). Perhaps it’s a minor internal change that works fine in RM, but not when imported by an app that doesn’t know about the change.

It’s similar to CP not publishing details of things like Fact Set and Template Definition files. Plugin authors have to work it out for themselves, and we’ve probably all been tripped up in the past by an undocumented change or user data being in unexpected format.

[Gary_G]

Mark;

CP was actually correct about there being a specific malformed citation template; right down to the syntax error in the template. It was nothing to do with the internals of RM9 itself. When I repaired the template, it imported fine. CP has stated that they will update FH to avoid the crashing in the noted case.Just wish RM9 would be that responsible in dealing with their product issues.

I should also note that they were able to determine that RM9 uses two forms of path addresses for images. They knew about one, but not the other. As a result, there were instances in which the import routine could not resolve the location of some media. Now that they know, they are planning to update FH to handle the previously unknown case. This is going to please RM9 "refugees", who have been scratching their heads as to why the FH import appeared to miss some of their media.

All-in-all, this worked out very well.