RM8 - Parents 'field' - Notes

RootsMagic
1

Although a (very) long-time user of RM (currently v8), I have recently become aware of an issue that I hadn’t previously noticed and would welcome any advice others have to offer.

I do occasionally use the notes section of the Parents ‘field’ (just under the Souce line, top left of the person page). Mostly, I use this to include a note which highlights when I have some doubts about the identity of one or other of the parents or to note any particular points of note. I also add any accompanying documents/images and sources.

What I had not noticed is that these notes do not appear in any generated reports. Of course, there is a workaround in as much that I can generate a new data field into which I can enter the same notes, image and source information.

My problem is that I have a large database and I have not yet found an easy way to identify those records which have entries in the notes attached to the Parent ‘field’ since the search facility does not seem to access this area of the database. I can, of course, go into each person’s entry but I have thousands of them!

I further issue is that I have for some years used Gedsite (an excellent program) to construct a large and quite sophisticated website as a far better way of giving access to my data than relying on RM. This too does not translate the Parent ‘field’ notes entriesor accompanying images and so that data is missing from my website.

I would be very happy to find that I am simply misunderstanding how the Parents field notes should be used (& where this outputs to in any report). But, failing that, could anyone offer a way by which I can easily identify which records contain entries in the Parents notes so that I can implement the workaround I have suggests above. I guess this could be done using SQL but that is something I have almost no knowledge of.

Incidentally, I have been using RM v8 for many months with increasing frustration about just how many facilities have not carried across from v7. The latest bugbear is that I can no longer produce Narrative reports - the program (v8.2.5) simply hangs, despite me fully uninstalling and doing a complete re-install twice: is anyone else still have that same issue?

I have almost decided to revert back to using v7. Is it safe to do a full GEDOM export from v8 and importing this back into v7 or do I risk losing data?

I’d be grateful for any help.
GeoffB

2

I have not checked Parent notes in RM8 yet, but in RM7, they did print in the Individual Summary reports. As for transferring to your website, have you opened the GEDCOM in a text editor and checked to see if the Parent notes are there? If so, then GEDSite may actually create a log file letting you know what didn’t transfer. I don’t recall for sure because I only used it once.

As for exporting backwards to RM7, there can be some loses, such as groups. I do believe that there is a list in one of the magic guides, that details what can be lost in a GEDCOM transfer. I don’t happen to have the link for it right now. I will look for it is someone doesn’t get to it before I do.

3

As far as data loss with RM’s GEDCOM transfer, see GEDCOM and Drag and Drop data loss

RM8’s process File => Export Data => Dropbox will create an RM7 database. It’s intended for use by the RM mobile app rather than by the RM7 desktop app. I have opened it successfully in RM7, but I suspect there are a few minor problems with it. I’m not sure of the current status of how reliable the RM7 database is that is created in this manner from RM8.

I’m still on RM7 myself because of a number of lingering issues with RM8. I probably would be willing to go ahead and start using RM8 in production right now if I could be assured that there was a sufficiently reliable path back to RM7. If I were in your situation of already having moved from RM7 to RM8 and needed to get back to RM7, I would study the File => Export Data => Dropbox approach first. If that wasn’t safe enough, I would use the GEDCOM approach despite its limitations.

4

The “Parents notes” of which you speak are properly called Family Notes. You can find them with an advanced search that uses Find => Note (Family) => Contains => string to find a Family Note containing the string.

In theory, you could find all the non-blank Family Notes with Find => Note (Family) => Is Not Blank. However, I find in both RM7 and RM8 that the search for people with non-blank Family Notes finds nearly everybody even though they don’t have family notes. It’s surely a bug. The family notes are stored in RM’s FamilyTable. Each row contains two individuals - basically a father and a mother. I can’t quite picture the nature of the bug, but it’s surely involved with RM’s internal Boolean logic associated with the fact that there are two individuals in each row of the table instead of just one. If there are particular strings you can search for, then the advanced search for family notes will work just fine and will find both spouses associated with the note.

Ultimately RM’s advanced search is finding people. For example, a search for a Birth => Date => Equals => 1910 is not finding birth facts where the birth date is 1910. Rather, it’s finding people who have a birth fact which has a date is 1910. This might seem like a distinction without a difference, and often there really isn’t difference. But sometimes there is, and the difference can be very confounding when it happens.

RM’s “family stuff” is very bad about not behaving in the manner in which a user might expect. For example, a Census (Family) fact is not for the whole family. It’s just for the parents, and it appears in the family section of reports along with Marriage and Divorce instead of being in the section of the report for either individual. Citations for a family are similarly just for the parents and not for the children. Citations for a family do appear in a report, but their footnote superscripts are just sort of floating in mid-air in reports and are not connected with any particular fact or text. That’s because families are not facts, and citation superscripts print with their respective facts. So a family superscript has nowhere to print.

I don’t use Family notes or Family citations or Family (Census). I fully expected that at least the search for a family note not being blank would work, but it obviously doesn’t. So this is a new bug for me.

5

The Note for a Couple (Family, Parents) is printed in the RM8 Individual Summary, Family Group Sheet and Narrative reports, provided that the checkbox to include Notes is checked. Not changed from RM7.

6

Not in my experience with RM7. I just went back and checked to make sure. I entered a note, and the only place in RM7 that it prints is the Individual Summary.

7

Both the above AND
Find => Note (Family) => Is Blank
Appear to return the SAME results

8

I get NEARLY THE SAME results, but not exactly the SAME results. In any case, something is definitely wrong with RM’s internal logic for this query.

9

You had me wondering so I went back and checked and the note appears in the same three reports in RM7 as I found they did in RM8.

10

My bad, somehow Notes got unchecked in the options.

11

So in summary, the family notes print correctly after all and it’s only the search for them that has a problem. Is that correct? I tested the searching but I did not test the printing.

12

There was an issue with the first release of update 8.2.5.0 for Windows users. An updated DLL used when creating the installer caused an issue creating reports. We have updated the installers with the original DLL. A new download of update (8.2.5) will resolve this issue.

Go to: Download RootsMagic 8
and click “RootsMagic 8.2.5 Installer” to download the new install, then run the downloaded file (make sure RM8 is not running when you run the installer).

13

Many thanks to Jerry, Kfunk, Tom and Kevin - very prompt and knowledgeable assistance as always. Being the ‘otherside of the pond’ there is quite a lot going on here (…mostly beyond credibility!) so it has taken me a little while to get back to you.

I had not appreciated that what I referred to as ‘Parents Notes’ was in fact Notes (Family). Furthermore, making an entry in the Notes section under Parents places this data in the Notes for each of that person’s parents.

Accordingly, as you have helpfully explained, using an advanced search on SEARCH ==>NOTES (Family) ==> is not blank does produce many results as does SEARCH ==>NOTES (Family) ==> isblank - in many cases the same records show up under both cases! Clearly something appears to be wrong in the search logic. ( Actually, despite running this on reasonably high spec Windows 10 PC with 16Gb RAM this search normally cases the program to freeze and on the odd occasion it has run through, it has taken around 2 hours to finish!!)

I have been able to refine this using SEARCH ==>NOTES (Family) ==> is not blank AND SEARCH ==>NOTES (Family) ==> Contains ==> e (or another common vowel tha can be expected to be present). This produces a far more meaningful result. However, these results also include all entries made in the SPOUSE (Notes) section.

So, when carrying out this search to locate an entry in the Parents (Notes) section, it only locates entries that appear in the SPOUSE (Notes) for that person’s parents and does not find the entry in the PARENTS (Notes) section for their child.

I can work with this though since I can delete the data entered in the PARENTS (Notes) section and instead put this into a new data field for that person. Otherwise the wording needs to be wholly editted since it was intended to apply to the child whereas it only shows up in the Individual Summary reports for the parents. A pain, but it can be done!

A complication is, of course, that in many cases I have already put data into the Notes section for a person’s spouse; any entry in that person’s child’s Parents (Notes) section merges with that making it confusing to disentangle what should and what should not be there!
This is, of course, a problem which I have caused for myself by not understanding how the PARENTS (Notes) section works.

There may be some perfectly sound genealogical logic in the way the program works in this regard but, if so, I must be missing it. I often have a need to make note in a person’s record which discusses their parentage (eg if I have doubts about which of two wives of their father was the correct mother) or indeed if a person did have more than one wife when only one actual marriage has been identified but their will names a different spouse. I shall, in future set up new fields to cope with this which I can search!

It will also ensure that the data is exported via GEDCOM and appears in my webpages against the correct person rather than, as I have discovered, buried in the narrative for their parents.

Thanks GeoffB

14

Many thanks Renee for your helpful response.

I was aware of the earlier issue with the DLL though, being in the UK I thought we had escaped this.

I have completely uninstalled my version 8.2.5 program and downloaded and re-installed the same version again a day or two ago. However, I am still experiencing a problem in running some searches that have taken up to 2 hours to complete (around 10,000 people in the database). Narrative reports which can be expected to contain hundreds of people are normally causing my PC (with 16Gb RAM) to cause the program to freeze.

I will try to record more accurately what parameters cause this to happen and come back to you if it continues to be an issue.

GeoffB

15

Slow Search is a topic @thejerrybryan has reported on extensively. You’re not alone but maybe your experience is extreme.

Setting aside the flawed DLL in the initial release of 8.2.5.0, RM has always frozen or choked on Narrative reports using Footnotes when the footnotes for a page consume something approaching the size of the page and need to but cannot flow onto the next page. Endnotes don’t suffer that problem.

The above is not to say that there can be nothing amiss in your database which might be the main cause of your problems. You might benefit from sharing your database file with RM Support and/or others technically inclined to see if they observe something abnormal in its performance.

16

For literally decades now, I have used endnotes instead of footnotes for all my reports from RM. I understand that you might prefer that your readers be able to look at the bottom of the current page instead of at the end or the report to see the citations, but it seems to me that footnotes have a lot of problems for genealogy reports.

  • In a well sourced database, footnotes can occupy a half to three fourths or more of each page. This can crash a program producing such a report. And even if it doesn’t crash the program, it can leave very little of each page as being “the report” and the number of pages of paper in the report can be enormous.
  • Duplicate citations are not merged as footnotes on the same page and they are merged as endnotes globally for the whole report. I’m pretty sure that RM is following proper and long standing publishing conventions in this regard. but with modern day computers it seems silly to me not to merge duplicate citations when they appear as footnotes on the same page. If publishing in general and RM in particular did that, then things like short footnotes and Ibid would not be necessary because things like short footnotes and Ibid would be merged out of existence.
1 Like
17

If you use SEARCH ==>NOTES (Family) ==> Contains ==> e then you don’t even need the SEARCH ==>NOTES (Family) ==> is not blank. if it contains an e, then it also is not blank.

You probably could even get by with search for a period instead of a vowel because a note that is not null is usually going to have at least one sentence that will end with a period. That would be a good workaround for RM’s “not blank” bug for family notes.

1 Like
18

My research suggests that the actual searching part of RM8’s Search is actually very fast, maybe even faster than RM7’s Search. However, RM8 adds two additional non-searching steps that are very slow and can make RM8 appear to be locked up. The first additional step is that RM8 appears to read the entire RM8 database to gather information that can be displayed in response to the search. The second additional step is that RM8 appears to use a humongous amount of CPU time in some very inefficient way to build a table of results that can be displayed. I have come to this conclusion by watching the Windows Task Manager during one of these long searches where RM8 appears to be locked up.

My typical results are less than 1 second to do the search, about 30 seconds to read the entire RM8 database, and about 60 seconds of CPU time to build a table of results that can be displayed. That’s a total of about 90 seconds I have to wait for my searches to complete before I can use any of the results.

I can’t explain why your searches take so much longer than mine. I also can’t explain why some RM8 users seem to experience very fast searches. I do know that I have ample hardware resources on my computer. For example, my main machine has a fast SDD disk. I have a second machine that has a slower HDD disk, and searches are much slower on that machine than they are on my main machine.

When I’m searching, I just want to get to the first hit or to the next hit as quickly as possible. If I want a list of results, I make a group instead. So the way RM8 does its searches and how long it takes is one of my least favorite features of RM8.

19

Please excuse my naivete, I am a relatively new user of RM. I too use Notes to note possible issues with data, not just for parents but for any fact or person or questionable sources. However, if it is something that I need to follow up on, I create a Task for that purpose. That is what these are for. I can’t imagine printing out hundreds of pages of Notes that add nothing to the record other than questioning facts. Tasks can easily be searched to find what needs to be verified.

To offer a suggestion to RM developers, I would add an other option to the Proven drop down to indicate something is “Questionable.” “Disputed” is not always appropriate. Then presumably one could search for Questionable facts.