I was using various applications to perform consistency checks, to find and fix errors in my genealogy database, and to check out the consistency checks of these applications, when I noticed something weird that led me to discover a serious defect in the RootsMagic PAF import.
I often use RootsMagic because both its import and consistency checks are fast; I have results in just few minutes. In contrast, Legacy 7’s import and consistency checks both take hours, but I still bother to use it from time to time, simply because Legacy 7 has rather extensive consistency checks; it is one way in which version 7 improved upon version 6.
Today, I was looking through the list of issues produced by Genealogica Grafica when I noticed that it lists issues that I was sure RootsMagic should list too but does not. A quick test confirmed that RootsMagic did not report these issue for the database import I had done a few hours ago.
There were some problems with the RootsMagic 4 consistency checks during the
beta period. Maybe I had seen such issues reported by RootsMagic 3, but not by
RootsMagic 4. Now, RootsMagic 4 should include everything RootsMagic 3 does, but
omission of a few checks would explain it all.
Just to make sure, I loaded the GEDCOM I had just loaded into Genealogica
Grafica into RootsMagic 4 - and found that RootsMagic 4 does report the
same issues.
This was confusing. I now had two databases open in RootsMagic 4. Both contained the same imported database. Yet for one, RootsMagic did report various issues, and for the other one, it did not.
My confusion did not last long. My main database is in PAF. RootsMagic can read PAF databases directly and I generally take advantage of that. Genealogica Grafica does not import PAF databases, so I had used a GEDCOM file, and had now imported that GEDCOM file into RootsMagic.
The difference between the two databases is that one created by directly importing the PAF database, and the other was created by importing the PAF GEDCOM for that database.
A few quick tests I did confirmed that this is the crucial difference. It should not matter, but it does; RootsMagic may find more issues with the same database if you import the PAF GEDCOM than when you import the PAF database itself directly.
Genealogica Grafica reported issues involving divorce dates, such as people who married before they got divorced, or divorced after they died. Such impossibilities are mostly the result of data entry errors such as transposed characters. Right now, I am not concerned with the errors themselves, but RootsMagic’s reporting of these errors; if you import the PAF database directly, RootsMagic does not report these issues, if you import the PAF GEDCOM, RootsMagic does report these issues.
It is not hard to figure out what is going wrong. If you import the PAF
GEDCOM, it all works fine, but if you import the PAF GEDCOM directly, issues
involving divorces are not reported.
RootsMagic Problem Search Report does not care how you imported or entered the
data. The only reason that it does not report any issues for particular event
types after the direct import is because those event are not there; somehow, the
direct import fails to import divorce events.
A quick test confirmed this to be the case. The RootsMagic GEDCOM import does
import divorce events, but RootsMagic PAF import does not.
If you import your PAF directly, divorce information is lost - and it is not all
that is lost either.
To enter a divorce event in PAF, you bring up the dialog box that shows the
marriage, and click the Options
button to bring up a menu On that menu, you choose the
first item, New Event/Attribute..
, which bring up the Select Event
dialog box.
You then choose to enter a divorce event.
There are many events and attributes that can only be entered by choosing them in that dialog box. Another event that you have enter using that dialog box is cremation. That one is not lost upon import.
The main difference between these two events is that divorce applies to a relationship, and cremation to an individual. Perhaps optional events for individuals are imported, while optional events that apply to relations are not imported. Well, it is not that straightforward. A quick test suggests that annulment and divorce filing events are not lost, while separation and divorce events are lost when the PAF database is imported directly.
Loss of data is always a serious issue. What makes this defect especially painful is that everything seems to import just fine. There are no errors or warning during import.
With FamilySearch ignoring the needs of its PAF users, many are looking for alternatives and quite a few may have switched to RootsMagic 4 already and many who did probably opted for the ease of the direct PAF import…
This problem is specific to the PAF import. It has to do with RootsMagic’s processing of PAF databases. Other import code is not affected by this issue. Importing PAF databases using a PAF GEDCOM works fine.
This defect is also specific to RootsMagic version 4. It does not apply to databases imported using RootsMagic 3 and then converted to RootsMagic 4.
However, I recommend against deliberately importing that way as a solution for this defect. PAF 5 and RootsMagic 4 are Unicode applications, RootsMagic 3 is not. If you go through RootsMagic, you are likely to mangle or loose characters. I recommend importing an UTF-8 encoded PAF GEDCOM into RootsMagic 4.
Those who relied on a PAF GEDCOM for transfer from PAF to RootsMagic are fine. Those who relied on direct PAF import now face a problem; their database is missing data and there is no simple fix.
Until a better solution is presented, they face a choice between two basic approaches. They have to choose between re-importing their PAF database through GEDCOM to make sure they have all their data but losing the changes and additions made in RootsMagic since then and figuring out what events were lost and then manually re-enter them in their RootsMagic database.
If you switched a few days ago and entered just a few new records, redoing the import is the easiest way to go. If you switched a few months ago, and entered lots of data since then, your choice will depend on the size and nature of your database.
The third option is to stop using RootsMagic and wait for RootsMagic Inc to provide a better solution.
RootsMagic could support re-adding the events that were lost by not only fixing the import code but additionally providing a tool that prints a report of all the events the original direct PAF import failed to include.
A slightly more advanced tool with a bit of comparison logic in it should be able to match most missing events to the current RootsMagic database, and let you decide whether to transfer each of these event or not. That would avoid the drudgery and possible data entry errors of re-keying those missing events.
This is not the first problem I uncovered with the import routines of RootsMagic 4. Shortly after it release, I noticed that it does import ANSEL GEDCOM correctly, but treats all ANSEL GEDCOM files as if they are ANSI GEDCOM. That particular defect was fixed in RootsMagic 4.0.1.1, released on 2009 Mar 30.
Bruce Buzbee confirmed defect, to be fixed in next update.
Bruce Buzbee has apparently taken some time to examine the defect, and posted a message on GenealogyWise revealing that it does not just affect several standard events, but user-defined events as well. All should be fixed in the next update.
RootsMagic 4.0.5.0 fixes the defect. The release notes were apparently written in haste; it says that RootsMagic now imports
user-defined divorce events
, which is a contradiction in terms. Divorce is a standard GEDCOM event. The RootsMagic PAF
import now imports divorces, vendor-defined events and user-defined events.
RootsMagic has not released any tool to help those who imported their PAF
database using an earlier version of RootsMagic 4.
Copyright © Tamura Jones. All Rights reserved.