Problem With Advanced Search, Family Fact, Multiple Spouses

RootsMagic
, ,
1

I first encountered this problem in RM7 which is still my production RM database. But the exact same problem also occurs in RM8.

I have a custom fact called Partners which is a couple fact (a family fact). I use the Partners fact for couples who were never married. I’ve been changing the way I use the Partners fact slightly and as a consequence the note for the the Partners fact now needs to end with a couple of carriage returns and a {}. So I need to find all the Partners facts which do not end in two carriage returns and a {} so I can add the needed text.

From my perspective, I don’t need the {}. I just need to be able to end the note with a couple of carriage returns. The {} is a dummy private note which doesn’t show up in reports unless you print private notes in reports, which I never do. From RM7’s perspective, I need the {} because otherwise RM7 loses the trailing carriage returns in GEDCOM. From RM8’s perspective, I need the {} because otherwise RM8 doesn’t even support trailing carriage returns in notes at all. If you type them in, RM8’s note editor just deletes them. So I use the {} to make sure that my notes that need to end in a trailing carriage return actually end with something other than a trailing carriage return, and a {} sequence after the carriage returns seems to be the best way to accomplish this goal.

There is no real problem in either RM7 or in RM8 in entering notes with the {} or in printing notes with the {}, etc. But there is a problem in both RM7 and RM8 in finding notes which need the {} and which don’t have the {}. For example, I have set up an advanced search as follows.

      Partner => Exists => Is True

AND Partner => Note => Does Not Contain => {}

The search works properly for individuals with no spouse, namely it doesn’t find such individuals.

The search works properly for individuals with exactly one spouse, namely it finds such individuals if and only if they have a Partners fact and if that Partners fact does not include a {}.

The search does not work properly for individuals with more than one spouse. For example, I have an individual with three spouses. Let’s call him John Doe. John Doe’s spouse #1 has a Marriage fact and no Partners fact. John Doe’s spouse #2 has a Marriage fact and no Partners fact. John Doe’s spouse #3 has no Marriage fact and does have a Partners fact. Said Partners fact does have a note with a {}. Nonetheless, John Doe shows up on the list of matches for the search. John Doe’s spouse #3 only has one spouse of her own, namely John Doe himself, so she does not show up on the list of matches for the search.

I’ve long been aware that RM’s searches for couple facts are a little squirrelly because the searches have to return a list of people but the couple facts are for two people in combination. This is not the first time I have seen searches for couple facts to return strange results. I think I can picture what is going on. The “exists” test is being met for at least one of the spouses but the test results are being applied to the person instead of to the couple. Then the “does not contain” test is being met for one of the spouses that doesn’t even have a Partners fact.

This is not an earthshaking problem that I cannot work my way around, but I wish it could be cleaned up a little bit.

2

Haven’t tested this myself but I think you should be able to use:
Mark: Partner => Exists => Is True
UnMark: Partner => Note => Contains => {}

3

That does seem to work. But you have to be making a group or color coding because searching does not support marking or unmarking.

4

Color coding allows one to then use Search’s Find to step through them (next/prior style).

5

In RM8? I don’t see how to do that in RM8.

6

Colour code first, then search on the colour?

7

Yes, I understand that you can do a color coding with marking and unmarking to make the marking and unmarking into something that is searchable, whereas you can’t do the marking and unmarking directly as a part of the searching. I was really asking about the “step through them (next/prior style)” which was a feature of RM7 that is not supported in RM8. I couldn’t figure out how color coding would provide the next/prior style of searching in RM8. I don’t think it does.

8

Search->Person Search (Advanced)->Find->IS (Color)
The next/prior functionality in RM8 is the Up/Down arrows through the search results list combined with the edit button. Equivalent to RM7 NextPrior buttons.

9

RM7: Search, Person List, Find is the same as RM8: Search, Person Search-Advanced, Find. If you need to filter with Mark and UnMark that’s only in the RM Explorer that groups and color coding use. If you create a group use the People List or sidebar index to display the results.

10

I probably should just let this one go because I have complained about it so much to no avail. But for me, it’s the furthest possible thing from equivalent. The key element that creates the lack of equivalence is the “combined with the edit button” part. If all I needed was the Edit button, I might agree to a certain extent. But I need much more than the Edit button.

In the first place, I need the Go To button. Which is to say, I need to see the person in the context of the Pedigree View or the Family View or the Descendant View. The Edit button puts you into the Edit Person dialog which does not provide that context.

In the second place, after editing a person I nearly always run a one generation narrative descendant report to view the changes I have made to the person in the context of what the changes look like in a report. It’s amazing how many little glitches you can see from in such a report that are difficult or almost impossible to see while you are in the Edit Person screen. So I also need the Go To button to be able to run the report because you cannot run the report from the Edit Person screen.

In the third place, I’m usually doing the Next thing as a part of a project to fix problems or find missing data. For example, I might be trying to find people who were alive in 1900 for whom I don’t have a 1900 Census record. So before I do a Next, I back up one person in the index list in the Find dialog to verify that the Next doesn’t find the person I think I just fixed. If if finds the same person again, then there is something that I haven’t fixed. And by the way, this makes my list of First and then Next people dynamic instead of static because the search automatically adjusts itself as I fix problems or enter missing data.

In the fourth place, my experience is that RM8 and RM9’s Advanced Find is profoundly slow. It usually finds all the people it is looking for very quickly - usually in a second or two or three. Then it spends many dozens of seconds reading through the entire RM database doing who knows what. Then it spends many dozens more seconds being completely CPU bound doing who knows what. I just want to to go to the First person more or less instantly just like RM7, and after that to go to each Next person, more or less instantly just like RM7. I would emphasize that the RM7 style Find Next does not have to start all over to do the Next. It starts from where it is, not from the beginning of the database and it usually gets to the Next person extremely quickly.

I actually have developed a workaround for RM8 and RM9 that provides me some but not all of the desired Next functionality. Namely, instead of doing an Advanced Search in RM8 and RM9, I make a group using the criteria I would have used for the Advanced Search. Then I filter People View by that group. I highlight each person in turn in People View and then I switch to some combination of Pedigree View, Family View, and Descendant View to do my work on the found person. The work usually involves editing the person and running a one generation descendant narrative report on the person to verify that my changes to the person are correct. Having done that, I can switch back to People View and manually highlight the next person on the list in the same manner as you suggest that I do with the New RM8 and RM9 version of Advanced Find. But notice that except for running the report, my workaround keeps me mostly on the main People tab. I find that switching Views is much less disruptive to my workflows and thought processes than is switching main tabs. In fact, the most disruptive part is of my workflow is running the narrative report, and that part of the workflow is also much easier in RM7.

My workaround involves keeping the groups I make for this purpose extremely small by including fairly restrictive search criteria when defining the group. If the group is not extremely small, then filtering People View by the group suffers from the same extreme slowness that I have described with RM8 and RM9’s Advanced Search. And that extreme slowness shows up every single time I switch to the filtered People View from one of the other views. The workaround for that problem is simply to keep the groups I’m working on very small, usually just a couple of dozen people and never more than a couple of hundred.

I think I’m just going to have to agree to disagree not only with RM’s developers on this one, but also with probably the majority of RM’s users. But to me the problem is very real. I have posted videos about the slowness of Advanced Search, but not so much about the back and forthing between the main People Tab and the Search tab. Everybody just tells me to use the Edit button to avoid the back and forthing. But I simply need much more than just the Edit button to get my work done. I also need various Views from the main People tab and also the ability to run reports.