Imported events by GEDCOM go missing if the event in BK was shown as "________"

Imported events by GEDCOM go missing if the event in BK was shown as “________”.

How can I get RM to read these lines?

Haven’t used BK in years so if the event has nothing in it “------” what do you expect RM to import? No date, no notes, etc.

A screenshot of the BK usage might help.

Thanks for responding, Jerry.
These items have dates and location descriptive text in.place, but where I’ve allowed the event type to be ‘____’, I’ve suddenly discovered they disappear when moved vi’s gedcom into roots magic.

Someone replied to your post.

| MadDog
August 11 |

  • | - |

Haven’t used BK in years so if the event has nothing in it “------” what do you expect RM to import? No date, no notes, etc.

A screenshot of the BK usage might help.

Information in a GEDCOM that a program doesn’t know how to work with just gets dropped. In this case the '___’ isn’t being dealt with as it would appear to be a rather non standard entry. When you imported the GED file, there would have been a file with an extension of .lst that would have listed any problems such as this. I am assuming you looked the the BK exported GEDCOM file and saw the the '_____" were in that file?

Since “----” is there, what do you want RM to assign to it? It could be a funeral, bar mitzvah, anything.

Best bet is to fill in the blank in BK with something gedcom & RM will recognize.

Don’t know why you would just have “-----” with date & location since it doesn’t tell you what happened there & then.

Assuming these items are life events and since the label would hopefully be unique, you could try a simple search & replace edit of the gedcom replacing ‘____’ with ‘Misc’ and see if that imports into an empty RM db.

[edit:] if that works you could create a group of everyone with a Miscellaneous fact, so that you can review/update these events as needed.

2 Likes

Thank you. Yes. I’d happily replace all the ‘______’ entries with ‘event’ which would be readable in RM.

But how can I edit the GEDCom or create a SQLite query to do this? There are probably hundreds of them across the whole database.
Peggy

Someone replied to your post.

| kevinm
August 12 |

  • | - |

PeggyJackson:

These items have dates and location descriptive text in.place, but where I’ve allowed the event type to be ‘____’,

Assuming these items are life events and since the label would hopefully be unique, you could try a simple search & replace edit of the gedcom replacing ‘____’ with ‘Misc’ and see if that imports into an empty RM db.

[edit:] if that works you could create a group of everyone with a Miscellaneous fact, so that you can review/update these events as needed.

  1. Do you still have Brothers’ Keeper and the BK file? If so, use BK to examine its database and what the ‘______’ represents. Is it a dated event? Does BK have a feature with which you can make a global change to its fact type? If so, do that and re-export. There may be an option available in the export dialog that would allow you to change the type to a GEDCOM standard.
  2. The exported .GED file is a text file and can be inspected and edited with a text editor such as Notepad or the much more powerful Notepad++ which supports regular expressions and such may be needed. Global search and replace will be your tool to make the change from ‘1 __’ to ‘1 EVEN’ but that may not be enough because it should be followed by a line ‘2 TYPE Misc’ . You should first examine the block of data for a person and see whether the structure of ‘__’ lines and their sub-levels correspond to the GEDCOM Event structure or something else. Below these numbered paragraphs is an example of a person block.
  3. SQLite is not nearly as efficient as a text editor is in working with text files and none of those ‘______’ tag blocks were imported into the RM database anyway.
  4. It probably would take less time than what I’ve spent crafting this reply for any of the respondents in this conversation to inspect your GEDCOM and ascertain whether there is anything useful to gain from editing it and, if so, do the edits.

Here’s an example of a person block in GEDCOM with a Miscellaneous event (highlighted by empty lines):

0 @I1@ INDI
1 NAME Jack /Spratt/
2 GIVN Jack
2 SURN Spratt
1 SEX M
1 BIRT
2 DATE 2000

1 EVEN ate a banana
2 TYPE Misc
2 DATE 12 AUG 2026
2 PLAC Toronto, County Durham, England, United Kingdom
2 ADDR 86 Pleasant Place
2 NOTE It was delicious.

1 DEAT
2 DATE 2060
1 BURI
2 DATE 2060
1 FAMS @F1@

The ‘ate a banana’ line beside 1 EVEN is the value for RM’s Description field. This is the format that RM will accept readily because it is the plain version that RM exports. BK probably does not support a street level address outside of PLAC so I don’t expect you to see anything in the ‘______’ tag block that can be converted to ADDR.

Dear Tom,

Thank you very much for your help with this – especially how to get in to see the GEDCom file. It seems that my false entries ‘____’ disappear even from the GEDCOM, so no wonder they never reached RM.

I think all I can do now is to work through the BK database, and correct all those ‘_’ lines to an actual event type. (Wish I’d realised that sooner – but at least, it will now be sorted …).

Thanks for your help – really appreciated.

Peggy

Dear Jerry,

Thank you very much for your help with this. I’ve now been able to look through the GEDCom file itself. It seems that my false entries ‘____’ disappear even from the GEDCOM, so no wonder they never reached RM.

I think all I can do now is to work through the BK database, and correct all those ‘_’ lines to an actual event type. (Wish I’d realised that sooner – but at least, it will now be sorted …).

Thanks for your help – really appreciated.

Peggy

1 Like

Dear Kenneth,

Many thanks for your help in trying to solve this. In the end I discover that the strange ‘____’’ items were never transferred into the GEDCom file at all – so I’ve had to resolve it by combing through my whole BK database, and correcting all those entries into something that will be recognised. I could wish I’d discovered this sooner – but all is now OK.

Many thanks,

Peggy

2 Likes