Using a MacBook Pro, we’re doing a RM 11 search for everyone who has a fact place Tennessee or abbreviated TN. The search doesn’t find everyone it should. It did not find was a census fact place in Tennessee. Here are the search criteria.
I don’t have time to test, but it looks to me as if the problem is that AND operations and OR operations are being combined, and that RM doesn’t provide a way to group them with parentheses. The first criterion of “everybody in the database” is not necessary. If you removed that one, you would only have an OR and I think that might work.
I’ll look at it some more later tonight. In the meantime, could you confirm whether some of the data expected to be in Place is in Place Details, or if maybe it only looks that way because you are displaying place information in reversed order.
First of all I do not think you want “Equals” you want contains – but the challenge would be the non-standard place “TN” might be hard to search for without getting positives. Do you place locations only have state?
I agree with Kevin. I think the core issue with the query is that you should use “Contains” not Equals. That will catch “city, county,state” type places as well as any entries with a stray space.
Also, am not sure why the query starts by marking everyone in your db. Usually the “Mark Everyone” statement is followed by “But Not” statements to prune people out. It doesn’t appear that’s what you want or need for this query.
I believe that statements 2 and 3 alone would suffice; just change the “Place =” statements to “place contains”. The logic should then become ‘any fact where place contains Tenessee or TN’. “TN” is such a wierd combo of letters that I wouldn’t expect you to get too many false positives. Finally, removing the initial “And” statement will avoid the concern Jerry raised of improper nesting which has been an issue in the past. [edit: just to clarify it’s not that your query is doing anything improper, the issue was that RM does not provide a way to add parenthesis to a query so it has trouble with queries that mix “And” and “Or” statements. The latest set of enhancements to queries have reduced that issue.]
I was not sure if he had comma in the naming structure (party of Why I asked if he only had state in the field). Assuming he has comma before that would work.
Because the default for Edit Person screen is to Reverse place names (Options within 3-dot menu)… Your second screenshot shows Relatives events where the Place name has not been displayed “reversed” because they have not been “normalized” to match the format of your other places (lacks comma between county and state).
I’m back to the computer. I think the question has already been well answered. Even so, I just now did a successful test as follows.
Criterion #1: Any Fact > Place > Contains > TN (turn on Match Case)
Run with Criterion #1 alone to be sure it works.
OR (don’t forget the OR)
Criterion #2: Any Fact > Place > Contains > Tennessee (I did turn on Match Case, but with string that long it probably doesn’t matter whether you turn it on or not).
My search “just worked”. Just use two criteria - not a third which is to select all. Use “contains” rather than “equals”. Use OR rather than AND to connect your two criteria. Make sure you Match Case on TN.
TY for input. One further question. If mix “and” and “or” functions, what is precedence, meaning which is executed first? Are all “and” executed before the “or” or vice versa?
I don’t believe that you’ll find this documented anywhere. My only observation is that the statements within a rule execute first. In your example - any fact with date after 1830 AND place contains “TN”. There is an implied “AND” within this rule even though it’s not displayed in the UI.
So in your example, the statements with the rules execute first:
any fact with date after 1830 AND place contains “TN”.
any fact with date after 1830 AND place contains “Tennessee”.
Then the joining declaration executes. In your case a union of the 2 groups.
If the query you’re trying to perform has multiple And’s and Or statements, I’d be inclined to try to break it into multiple steps to controll the order of execution. For example, make groups first and then create search rules based on the groups. I’ve not had to do this in practice with this new rules feature.
yes agreed what the user intends and the actual execution are not always on same page.
Much easier with true AND / OR and Parenthesis if you come from a programing background ( even EXCEL)
Sidenote: The upgrade that introduced Advanced Search (as a set of rules) appears to be an attempt to simplify some of the confusion/problems that users experienced (in earlier versions) while trying to reason about how the order (precedence) of logical operations resulted in “gotchas”.
Under the new feature, within each rule, the conditions chosen are effectively “implicit” ORs -or- ANDs to filter the Set selections. Now, external to each rule, an additional separate level of precedence AND, OR, BUT NOT (alongside being able to move the rules up -or- down) allow for affecting Set selection -and- displaying the “potential” filtered selection result (is that attempt to make logic clearer).
Operating with your example, the AND can ONLY operate upon the selections to the overall Set (made prior) involving MARK -and- OR.
In human wording, the subsequent (lower order of precedence) AND, can only affect the set of persons who have a birth fact place containing Vermont or Maine (to further “filter” down the selection). That can ONLY be people with a single birth fact place that contains BOTH Vermont AND Massachusetts, OR contains BOTH Maine AND Massachusetts, OR there are two birth facts (each) with one or more of those combinations. Any other criteria in that AND -and- further subsequent ANDs are still only acting upon the Set created earlier (in the higher precedence selections to the SET) with Mark -and- OR.
correct - better worded than I.
Order does matter. I believe in general whenever OR’s are involved they should be at top and before ANDs. I got 144 hits – with that search (which looks correct/expected results). If I change the order it will jump over 2000 (not what is desired)