When you import from Family Search or a GEDCOM or create a new person, the birth and death facts should automatically be part of the individual profile even if the fact does not exist or is not entered. Everyone is born and will die. RM does create the fact if information exists, but it is not created if there isn’t any information.
Screen shot shows an imported person without the fields present and what I suggest as the additional blank fields.
RM doesn’t create blank facts for people. If they are not added when a new person is added then you have to add them afterwards.
Yes, I know, that is why I suggested a request for a change. What is the harm of placing the empty field in the profile from the start? None that I can think of. The benefit is that you don’t need to use the + button, select the fact and then add it. I worked in Info Tech and reducing steps/clicks is important to usability and reduction of repetitive motions.
Ancestry and Family Tree Maker both have a Birth, Death field available when a profile is created with a GEDCOM import. You do not need to create the field, it is just there for whenever you need to update it. My own profile doesn’t have any information in the death field (obviously), it is just present. Again, reducing steps/clicks is preferential to increase usability and reduce repetitive injuries.
I work with Facts. If the person is not dead or I do not have death details then I do not want a Death Fact in my tree. You would probably get Death = Unknown in some reports when the person is still alive.
If you worked in Info Tech, then you are probably well aware that adding extraneous data into the database is more problematic than saving saving a few mouse clicks. I am assuming that based on your job, you are at least familiar with how a relational database works (or in this case, a library that emulates a relational database).
I’m all in favour of efficiencies but without extraneous data. Maybe the two can be met by a redesign of the Edit Person screen to have entry fields for Birth and Death when such Facts are not in the database. The Add Person window has those fields because those facts and the person record cannot already exist in the database. Doing so for an existing person record is more complicated and I don’t know whether the Edit Person window could support such missing records as though they are virtual facts in the format you’ve proposed.
Other requests along this line that have never been fulfilled include more direct access to frequently used or user favourite fact types when adding facts in the Edit Person window.
kfunk, correct adding extraneous data to a database is undesirable. Adding the blank fields to the profile in the app does not need to create data in a data base until the field is used.
The reason I added this feature request is I imported my children’s father’s line into an existing tree on RM from Family Search. I had 573 individuals born before 1900 without a death field. I did the research and found more than 500 death dates. That resulted in 5,000+ clicks to add death fact to the profile (+ for add fact, select death fact, select OK, enter data, and √ to add the fact to the profile, and a click to close the profile). 3,000+ could be eliminated by having the field exist on the profile, that’s not a few clicks.
I like this app in so many ways but the number of clicks to add facts and sync is daunting when dealing with a tree of 23,000+ individuals where I am attempting to find birth, marriage, death, burial and census facts where they are missing. I’ve been using it for only a few weeks and my carpal tunnel pain has flared from the excessive clicking required.
After these few comments, it appears that it is not a concern for others. 
Sql might be the way to go to add B&D to FS or Gedcom files prior to adding to RM.
I never directly import to RM but rather create a new database with FS info and then add as needed. Doesn’t muck up my data that way.
I don’t think anyone has said that. In fact, I believe those of us who are veteran RM users of previous versions are all appalled at the inefficiencies of the RM8-9 user interface which was supposed to (or so we hoped for) make significant improvements over those of RM7. In a few respects it has while in other equally or more important areas, the manual operations count is worse. What has been objected to is the addition of empty Birth/Death events to person records as a means of click-saving.
That objection could, of course, be answered by making it a user option for such events to be automatically added. Or, as agreed, that such default Birth/Death events be merely fields on the Form, not records.
@MadDog suggests some intermediate processing with SQL between FS and your working database. The adding of a Death event when none is present could be similar to the process for setting the Living flag. Here’s an outboard procedure I developed some years ago to Set Living that might also be a basis for adding a Death event with an estimated year:
https://sqlitetoolsforrootsmagic.com/living-flag-set-globally/
Once everyone has an estimated Death event, then it should be possible to add an estimated Birth event when neither Birth nor Christening are present.
I think I’ve seen other software that does generate estimated Birth and Death events. These should be helpful in the sidebar Index and other areas which display the Years of the two events.
If a blank field is added but nothing is entered into it, I would think that a new row in a table would have to be added as well as the external keys being added into the row.
I’m not sure about this, but you might also get some rather stupid looking sentences in reports. If you have an empty death fact on a living person, will the narrative report that that person died? Not sure about that, but right now I’m feeling too lazy to test it out.
@Terry, you’ve written it twice and it’s a valid opinion. We just differ and that is OK.
@MadDog you must be a programmer. I was an business analyst in IT. Wish I knew how to use SQL scripts.
@Rwcrooks i’ve always envisioned a database as a complicated Excel spreadsheet (probably a huge misconception). But I know that when I designed any app field, the programmer needed to define it as for where to save it if used, min/max values for the file it was saved to. So in my imagination…
Relational dbs are not one record with everything in it like your excel example but a series of linked and related tables, with the data normalized.
Check out the rootsmagic sql site you’ve seen mentioned. The sql manager is easy to install and then you can see all the different tables.
I’m far from an sql expert but I’ve used some of the code on the site to really speed the removal of errors in my db.
