RM9 has default setup for fact types.
For example fact type Birth has under use Date: Yes, Place: Yes, Description: No.
If I change Description to Yes and then created GEDCOM shows lines
0 _EVDEF BIRT
1 TYPE P
1 TITL Birth
1 ABBR Birth
1 SENT [person] was born< [Date]>< [PlaceDetails]>< [Place]>.
1 ROLE Witness
2 SENT [ThisPerson] witnessed the birth of [person]< [Date]>< [PlaceDetails]>< [
3 CONC Place]>.
1 ROLE Doctor
2 SENT [ThisPerson] delivered [person]< [Date]>< [PlaceDetails]>< [Place]>.
1 PLAC Y
1 DATE Y
1 DESC Y
Now I import this GEDCOM back to RM9 and fact type Birth is back to default
Date: Yes, Place: Yes, Description: No
Why it is No, when GEDCOM has line “1 DESC Y” ?
It is a bug in RM9 or needs to be done something after importing GEDCOM?
RM is doing what it is designed to do. Customisation of standard fact types does not carry over from GEDCOM. I assume the thinking was that users would not want external customizations (or, for that matter, the default settings) to override the way the standard fact types have been set in the destination database.
It could be argued that there are exceptions such as yours and there should be options for the user ro choose. Enhancement request!
Have no idea why it happens but YES it does happen and yes it is checked to include in a gedcom-- I had customized the marriage fact by checking description in the original file— as you can see from the screenshot, when I made a gedcom and opened it, the info is not there.
What you need to do is go back into the database you just created – USING THE FACT LIST, go to the fact that you customized --edit it by checking description again-- hit okay and your info is back
Yeah, and go thru all default fact checks where any change was done. And if you forgot to do this the next time after export and import, to and from GEDCOM, your data on this field are lost.
What is a good reason, why RM9 will not bring this change?!?
I don’t think this is a bug. It seems highly probable that the description field is transferring correctly but the use of the data is turned off in the new database. Does turning the description field back on make the data appear without needing to import the GEDCOM again? I suspect it does.
When you say that you import the data “back to RM9”, is it back to a pretty much brand new database? If so, you really are going to need to turn the Description field back on.
I do sympathize with your frustration. It seems to me that the Description field should be enabled by default for many more of RM’s fact types and perhaps for all of them. It also seems to me that RM’s fact type list should be much easier to manage. I think the whole fact type table should be displayed in a grid format like a spreadsheet with a column for each option so you could see all the options for all the fact types at a glance. And a single click should be all that’s need to turn on or off all the options for any particular column.
We need an answer directly.from devoloper. **What is rule for each fact type for enabling or disabling description field? ** Every user has a different need. I belive every default fact check should have description field checked.
Also the same problem is with Sentence template. I changed the Principal sentence wording for Birth from “was born” to “wurde geboren” and created GEDCOM for my friend in Germany.
0 _EVDEF BIRT
1 TYPE P
1 TITL Birth
1 ABBR Birth
1 SENT [person] wurde geboren < [Date]>< [PlaceDetails]>< [Place]>.
1 ROLE Witness
2 SENT [ThisPerson] witnessed the birth of [person]< [Date]>< [PlaceDetails]>< [
3 CONC Place]>.
1 PLAC Y
1 DATE Y
1 DESC Y
He also has RM9. After importing GEDCOM the sentence is back to “was born” and description field is uncheck.
**If RM will allow you to make changes, RM should keep this changes for data exchange between two RM users. **
That one is troublesome. The GEDCOM you created did contain the German version of the Birth sentence. However, my understanding is that if you have a custom defined fact type in your database and if you export a GEDCOM including that fact and if you enable “Extra Details (RM Specific)” on your export and if you import the GEDCOM into RM and if the RM that is importing the GEDCOM doesn’t already have that fact type, then the sentence will be imported. That’s a lot of conditions that have to be met, and in all other cases the sentence will not be imported.
The Birth fact is a built-in fact. Therefore, it will already be in the RM which is doing the GEDCOM import. Therefore, the sentence for the Birth fact in the GEDCOM will never be imported.
RM has another way to import fact type information than via GEDCOM. Namely, if there is already another RM database on your computer that has fact type information you wish to use in your current RM database, then you can use the following tool to import the fact type information from the other RM database: File => Import Data .=> Import Lists => choose the RM database from which to import => Fact Types. However, my experience with this approach is that it also doesn’t work except for Fact Types that are not already in the RM database into which you are importing. And again, the Birth fact will already be in the RM database into which you are importing.
My understanding of the rationale for this design is that it is to protect the RM database into which you are importing from being damaged by the GEDCOM which it is importing. But the net effect is that for the most part, RM’s sentence templates cannot be exported and imported.
This problem is actually worse than it seems. That’s because RM depends heavily on its drag and drop tool to be able to move data from one database to another. For example, the RM Helpdesk sometimes recommends doing a drag and drop of an entire RM database into a new and empty RM database as a means up cleaning up corruption that rarely but sometimes occurs in RM’s underlying SQLite database. But RM’s drag and drop tool uses GEDCOM as its data transport mechanism. That means that anything that’s lost on GEDCOM export/import is also lost when using RM’s drag and drop tool. And one of the things that is lost on GEDCOM export/import is sentence templates except in the very special case where the database into which the data is being imported doesn’t already have the fact type being imported.
RM needs a tool that will actually transfer sentence templates from one RM database to another without exception.
If your colleague wants to use RM and only on this one-time dataset, a workaround for you would be to make a copy of your database file, strip out from it what you do not want him to see and send him that edited .rmtree file. That way, GEDCOM will not have come into play at all and your customisations of the standard fact types will be preserved.
The downside is that sending him future snippets that he imports into his database will not carry any subsequent changes you may have made to the standard fact types as they won’t be transferred either by import or drag’n’drop. Other users would regard that as good protection.
Yes, this should work and it is NOT working for fact types.
At least this BUG NEEDS TO BE CORRECTED.
Thanks everybody for any advice on how to go around, but again :
What would be the reason not to transfer customized fact type ?
Why description field by default is on some fact types checked and not on the others?
This mystery needs to be explained or solved.
Sorry @starmanFrank – I just tried what Jerry suggested for importing fact types and it worked just fine for me on my customized fact as well as on the default marriage fact that I had checked description on
I have learn over the years that IF something doesn’t work such as importing facts the 1st time to try again as sometimes either I missed a step or most of the time, there was a glitch in my computer that caused it to not happen…
I have also learned the hard way that you should always check a gedcom to be sure all the info you wanted was transferred as some times you end up with a bad gedcom even though from your perspective it looked like everything went fine on making the gedcom
Vaguely recalling it is related to a GEDCOM specification. Some fact types such as Birth are differently specified compared to what are known as Events. In GEDCOM, iirc, there is no provision for what we call Description in the Birth fact but there is in Event type facts. The RM developers adopted a database structure that is common to both Event-type and Fact-type data.
That’s why Description is turned off for Birth; that makes it comply with the then GEDCOM spec.
Now I may have this entirely wrong; it has been a long while since I looked into GEDCOM on this matter. Regardless, the rigidity with which RM protects users from themselves is an ongoing frustration for those of us who want more control over their databases.
Just to try to make sure I’m not a totally crazy person, I just now created a new and empty RM9 database and imported the Fact Type List from my production RM9 database. All my custom fact types imported just fine, but my customizations for RM’s built-in fact types imported not at all - neither the sentences nor the options like enabling the Description field.
Given that yours worked, I wonder what is different. Is it possible to post screen shots from before and after you did the import?
Would you confirm that the list of enhancement requests includes one to provide the option for overriding that protection of Import (Lists and GEDCOM) and Drag’n’drop so that user customisations of standard fact types and their settings may be carried over from database file to database file?
That said, I recognise that there are complications for custom roles for standard facts and for custom fact types, especially when there are matching ones in the target database, for which some additional controls and procedures will be needed, such as inclusion/exclusion and separate/combine.
tried it your way with a new database and imported just facts from my test database – and it did NOT work-- then went in and tried importing facts from another file into a new database and it did work
can’t tell you why it works sometimes and not others BUT it does NOT overwrite the original BUt rather puts a secondary fact with the same name in the list…
I don’t think it’s so much a request to overwrite as it is a request for a tool to be able to transfer fact type information from one RM database to another. An option to overwrite would be one way to satisfy that request. But there could be other possibilities.
Did you check that your second source file from which you say a secondary Divorce fact was created when its fact types list was imported does not itself have two Divorce fact types?
