My proposed import from Rootsmagic to FH


Edward Sneithe
 

I have had FH for about 18 months. Until a fix to V7 there was an error in the narrative code that prevented me from converting to FH.

Now I have a slightly different issue. There are some that don’t want to leave Rootsmagic until v8 is completely resolved bringing it up to V7 in functionality and then decide.

In the meantime there are way too many features in FH to ignore so I was working on a scheme that would allow us to move projects from RM7 to FH7 with no loss of data and have come up with the following scheme.

We must be able to retain our customized facts and sentences. We have not created any custom sources. RM7 puts all this in the “extra details” when  exporting. When importing FH7 finds thousands of errors concerning all the data from the “extra details” so we have decided that they will not export cleanly and will not include them.

·       We must duplicate all facts and sentences in FH so FH can find the appropriate fact during the import.

·       We must convert all the {} to identify private notes in RM to [[ ]] that will signify private notes in FH. I have an editor with a macro for this.

·       We must convert all 1 EVEN descriptor to 1 FACT descriptor. FH 6 rejected these as errors whereas V7 now seem to accept them with  warnings. This also has a macro if that is wise.

·       I have tried this and it seems to work.

We must also do this with sources if that applies.

Color coding of people also runs into a problem because the color coding info is only contained in the “extras”. During the import saying the 1 _COLOR 1 line is rejected.

I have created a couple of new facts in RM and FH that will never be able to be printed so the  reports are ok. When creating a chart I can check for the presence of a particular fact and alter the chart as appropriate.

Shared people work if the shared person is in the project file but if it is text only RM puts out a _SHAR gedcom line which FH rejects. I will convert all of these people to people in the database but with the surname preceded by an * just to differentiate.

I will need to do more testing to see if any more issues arise but this seems to be a good start. Now does anyone have an opinion if this is a good idea or not and if there are any better alternatives.

I am not recomending this as a general practice but only that it seems to work for me.

Join family-historian@groups.io to automatically receive all group messages.