* Exception log question after gedcom import from RM7

[bubbalicious]

Okay, I'm a new FH6 user and yes, I got the handy-dandy official book when I got the program.

I did a gedcom import from RM7, just to jack around in FH6 and get used to the interface, where to find stuff, made some changes, etc. So far, it seems pretty straightforward. My *real* cleaned-up RM7 gedcom export is what I just imported as a new project into FH6 and what I will be using.

I looked at the exception log for the new project and I'm a little concerned about the "excluded branch line" at the end of the report. What do I need to know about this exception log? Are there things I need to fix?

Thanks for your help, and if it talks about this in the book, please point me in the right direction! Thank you!

Nikki

[tatewise]

Welcome to the FHUG Nikki.
I've moved this to the Importing and Exporting Forum that is more appropriate.

Did you see the how_to:import_from_roots_magic|> Import from RootsMagic (RM) guide, although it does not help much with your excluded branch line problem. It does give advice about Handling Uncategorised Data Fields (UDF) that will almost certainly need sorting out.

Please copy & paste fragments of the exception log reporting the excluded branch line problem and any other problems, and we will advise. I think the only explanations are at the head of the log, and often need some familiarity with FH and GEDCOM terminology.

BTW: Don't overlook the how_to:key_features_for_newcomers|> Key Features for Newcomers.

[Jane]

As Mike says if you post the section we can see the error.

A good rule of thumb if there is nothing you recognise as notes or other information it's nothing to worry about too much.

[bubbalicious]

Thanks, Jane and Mike, for replying to my post expeditiously; appreciate it!

I've done a couple of things since initially posting last night, one being deleting the project I brought in yesterday because I hadn't done anything in it yet. I went and looked again at the "importing from RM7" knowledgebase article, and did the one thing I had not done previously, which is un-tick the "Extra details (RM specific)" box, and re-exported the gedcom again. I then deleted yesterday's FH6 project and re-imported the "new" gedcom today as a new project again, and have not done anything in it yet.

I then ran the Show Project Statistics plug-in and made its reports as a pdf and a csv (which I then brought into Excel). It is quite enlightening and I see right off that a "HdstnPhoto" fact in RM is only the date that I took the gravestone pic at the cemetery and put it as a date of September 2010. I can only surmise that no specific date is behind the "fact age is too large blah blah blah" thing but I'm not too concerned about that because those facts could be given a specific date (like when I actually took the pics).

Secondly, I ran the exceptions report again, and I see what records are discombobulating FH6 and it's mainly because of facts (events) I made in RM7 that apparently do not translate well into FH6. An example would be "INFO ONLY: Detected & fixed invalid use of EVEN (event) tag: "1 EVEN applied for a Social Security number at 25 years old." I can only surmise, again, that there is no comparable fact that covers this in FH6, and maybe I need to make that a miscellaneous fact or something like that.

Luckily, this time the exceptions log had nothing about excluded branches. So, the upshot here is that I need to fix what the project statistics report found as "Lines marked "INFO ONLY:" indicate data that has been successfully loaded, but where special action was needed to load it e.g. GEDCOM errors detected and automatically corrected by Family Historian." Some of its findings will be ignored because these people are way-off cousins whose only info I know is their name and maybe a birth date; it's not worth my time or effort to find out anything else about them.

Looks like I have a bit of work to do, eh? I think a lot of the report findings have to do with RM7 being an SQLite database-driven program whereas FH6 is gedcom-driven. I'm just going to chalk all this up to each program having its own way of doing things and go from there.

Thank you again for your help.
Nikki

[tatewise]

OK, so the [kb]|[/kb] advice did help

The point about fact Dates is they should be dated when the event happened, not when you discovered it.
So the gravestone event should have the date of burial or perhaps the date the gravestone was erected.
The photo image Media record has Date and Note fields to record when you took the photo.

The point about EVEN (event) tag data is that events should not have such text attached.
Whereas, attributes, such as Occupation, Education, Religion do have a data value to define the attribute.
However, many products including RM do not enforce that GEDCOM specification rule.
So there is nothing fundamentally wrong with your custom fact and FH V6 will happily work with it, except for the data value that FH has moved to the Note field. Later you could convert it to an attribute if you wish and move the data value back.
BTW: Later you will need to review the Tools > Fact Type definitions for all your custom (i.e. non-standard) facts as explained in glossary:work_with_fact_sets|> Work with Fact Sets/Fact Types.

Don't overlook how_to:handling_unrecognised_data_fields|> Handling Uncategorised Data Fields (UDF) and the other Related Pages in how_to:import_from_roots_magic|> Import from RootsMagic (RM).

[bubbalicious]

Thanks, Mike, for your reply!! I have a bunch of Knowledgebase articles open in my browser for FH6, and I won't be doing *any* data entry until I get all this stuff sorted out.

Thanks also for the info on the gravestone pic. Don't even ask me what the he__ I was thinking 19 years ago when I put them all in as "HeadstnPhoto" instead of "Gravestone" or "Gravestone Marker" in RM7. Well, they will all be changed now to the appropriate fact type -- is there a fact type in FH6 to use for this? As for custom fact types, luckily I only made two of those in RM.

And a question with regard to one of the custom fact types that I made -- if I'm putting in somebody's obituary (a custom fact I made) with a source of "newspaper, print edition," what would be its equivalent in FH6? Yes, it should be attached as a source for death, but many obits also have other pertinent info such as birth, marriage, occupation, etc., and should be a source for those also. And, many times my relatives way back when put the obit in the newspaper the same day as the death, so obviously an obit cannot come before the death, even if they have the same date. In RM, I was able to change the sort date for the obit so that even if they were on the same day, they showed up correctly in the timeline. Is it somewhere in the v6 book as how to accomplish the same thing in FH6?

I *do* have the Fact Types/Fact Sets kb articles open, as well as the UDF page, and they are very helpful.

Thanks again, and I look forward to your answers!
Nikki

[tatewise]

Both your main questions should be answered by using Source Citations.
If you are not familiar with the concepts then there is another [kb]|[/kb] article for you to study.
See glossary:sources|> Source Records which is one of the topics in how_to:key_features_for_newcomers|> Key Features for Newcomers. See also how_to:index#recording_facts_and_sources|> Recording Facts and Sources that illustrates several practical examples.

I would add the gravestone details as a Source record with the image attached to its Media tab.
Its Text From Source transcript would record the memorial wording on the gravestone.
It would be quite common for a husband & wife and perhaps other relatives to all be recorded on one gravestone.
So the Death &/or Burial events for each person mentioned would all cite that same Source record.
Thus there would be no custom Gravestone fact at all, because the gravestone is not an event, but evidence of the death & burial similar to a Death Certificate or Parish Register Burial that would form their own Source records.

The case of a Newspaper Obituary has similar characteristics to the above.
The Source record would hold the newspaper Media image and Text From Source transcript of the obituary.
For the person who died you could have a custom Obituary event dated when the newspaper was published, and that cites the Source record.
Other details revealed by the Newspaper Obituary such as Birth, Marriage, Occupation, etc, will have facts against the associated people that also cite the same Source record.

Maybe you had not realised that a Source can be cited by many facts, and a fact can cite many Source records.
It is important to keep a clear distinction between facts and the source material from which they are derived.

To change the order of identically dated facts, first see the how_to:sorting_children|> Sorting Children, Spouses & Facts into Order and then To manually re-sequence Facts...
Facts that have the same Date should remain in the order you establish.
FH does not have a built-in Sort Date capability, but there is a Plugin that adds a Sort Date capability although not 100% perfect. However, you should not need it for the specific equal Date case you mention.

[bubbalicious]

Once again, Mike, thank you for your detailed answer. I appreciate your time and effort.

Being no stranger to genealogy and genealogy research since the early 1990's I've used my share of genealogy software, starting with Family Tree and then moving to Legacy and then to TMG and then when TMG was not going to be updated, settled on RM. I moved to FH6 because I like the layout and seeing info at a glance instead of the incessant clicking to do anything in RM. Each program has its own way of doing things and I'll get used to FH6 in short order. But, I digress.....

Prior to your last post, I had thought of an obituary as a fact but it makes sense the way you explain it in that it's a source for an event or fact, and I'll start thinking of it in those terms. And many times, as you mention, that source can/will be used for other facts for that person (or people). Obits are goldmines of information!

As for the gravestone images, I'll have to determine if I want to attach media, not having done that in other programs. To be honest, I'm very leery of images ballooning the program into the stratosphere size-wise. You would not believe how many gravestone/birth/death/marriage images I have! The media thing might be best left for a later time...

I see why you are, indeed, a Megastar!

Nikki

P.S. I saved your last answer for reference.

[tatewise]

Sorry! I assumed your "HdstnPhoto" came with a photo image.
Don't worry about having too many attached Media as FH V6 handles them very efficiently.
My Project has more Media records (~1100) than Individual records (~600) and is quite small by comparison to many other users' Projects on these Forums, that are more than ten times that size.

However, if you are uncomfortable with Media images then don't use them.
But do record their transcript, and do record where the image can be obtained.
Otherwise, when you or others review your data in years to come, it won't be certain where the facts came from.

[LornaCraig]

To be honest, I'm very leery of images ballooning the program into the stratosphere size-wise. You would not believe how many gravestone/birth/death/marriage images I have!

That's one thing you don't have to worry about. FH can handle any number of media items without difficulty. I have over 5,000 media images, held in 57 sub-folders of the Media folder.

If you have to start adding them from scratch it may seem a daunting task, but for future data entry take a look at the Ancestral Sources add-on program which automates much of the work when recording censuses, BMD events, etc, including adding images to source records.

[bubbalicious]

Thanks for the Ancestral Sources info, and I'm in the process of checking that out; have the link to it open in my browser tab.

Nikki

[tatewise]

Nikki, beware of going off learning about the intricacies of using FH and AS before you have tided up such as the UDF and any other irregularities imported from RM. Many of your recent questions are not to do with the importing process, and would be better asked in the FH General Usage Forum. Don't take that as a rebuke, but simply that we like to keep the topics focussed on the original Subject.

[bubbalicious]

Point taken, Mike, and I didn't see your post as a rebuke I am thinking like you, in that any irregularities such as the UDF, etc. should be dealt with before attempting AS. I as think I mentioned previously, I did run the project statistics, saving its reports, and will be looking at what it came up with also before anything else is done. One step at a time, amiright?

Nikki