Performing a find that looks for two different criteria at same time

[Craig_ST]

I know that this will be very simple, but I am simpler yet! 

 

I have a contact database and I want to write a script that looks to see where different contacts are located and selects them if they are from either of 2 of 5 different possible options, in this case NORTH METROPOLITAN and SOUTH METROPOLITAN.  If I make a script with two Perform find steps, it finds the North ones first, then looks for the South, but because it has already found the North ones, there are now no South ones in that list, so I know I need to join  these perform find steps in to one, but do not know how.

Any help greatly appreciated,

Craig 

[comment]

See if this helps:
https://fmforums.com/topic/107949-finds-from-two-tables/?do=findComment&comment=486088&_rid=72594

 

[Craig_ST]

Thanks, 

 

I will give this ago - just one question in advance though, this appears to be looking in different tables, the find I need to do is for different values in a drop down list for a field in one table one - would this work the same way?   

Craig

[Craig_ST]

Actually, I got it to work with Perform Find and then Extend Found Set! 

 

Craig

[comment]

Not sure what to say. I suggest again you read the linked answer.

[fabriceN]

If you want to do it in one go, then :

Enter find mode
Set field [ location ; "==NORTH METROPOLITAN" ]
New Record/Request
Set field [ location ; "==SOUTH METROPOLITAN" ]
Perform find

 

[comment]

I am not entirely convinced it's necessary to use the "==" operator here (and consequently lose the speed of an indexed search).

 

[fabriceN]

1 hour ago, comment said:

I am not entirely convinced it's necessary to use the "==" operator here (and consequently lose the speed of an indexed search).

 

Wow! your reply to what I thought to be a casual message makes me think I'm about to learn something.
Can you elaborate on this?
According to my tests (a very long time ago, I admit), == was on the contrary very fast, probably making use of the "per line" index.

For instance it was much faster on UUIDs, because the hyphen is interpreted as a word separator if between two digits. (which makes the find not only faster but also and more importantly more accurate)

If you have a minute to spare, I'd be greatful.

[comment]

43 minutes ago, fabriceN said:

makes me think I'm about to learn something.

Or maybe the other way round?
 

Anyway, AFAIK an exact search does not use the index. This is based, among other things, on the following observation: suppose you have several records that have similar entries that differ only in the last few characters beyond the ~100 characters index limit  - for example:

abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz01
abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz02
abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz03
abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz04
abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz05

Searching for:

abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz03

will find all 5 records (as expected). Searching for:

==abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyz0123456789abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz03

will find the single record that matches exactly the search phrase. 
 

The speed tests I performed (admittedly also very long time ago) seem to support this conjecture - see:
https://fmforums.com/topic/94328-find-mode-symbols-etc-and-text-field-index-usage/?do=findComment&comment=431378&_rid=72594

That said, it needs to be said it's all guesswork. As is often the case, the documentation provided by Claris is inadequate and we are forced to rely on our own testing in order to asses the behavior of the black box. Such tests are very difficult to construct and perform reliably and conclusively.

  

 

 

[Ocean West]

And wouldn't changing a particular field to Unicode also change the behavior as to what a break character is? 

 

 

[Craig_ST]

Thanks for the additional replies, I did solve this using the Perform Find and then Extend Found Set! options but good to know there are other ways to do things.  

 

Edited May 9, 2023 by Craig_ST

[fabriceN]

12 hours ago, Ocean West said:

And wouldn't changing a particular field to Unicode also change the behavior as to what a break character is? 

 

 

Yes it does. That's what we do.

13 hours ago, comment said:

The speed tests I performed (admittedly also very long time ago) seem to support this conjecture - see:
https://fmforums.com/topic/94328-find-mode-symbols-etc-and-text-field-index-usage/?do=findComment&comment=431378&_rid=72594

 

Thank you!
It would be interesting to see what it gives with multiple words (there's only one per line in your example).

[comment]

53 minutes ago, fabriceN said:

It would be interesting to see what it gives with multiple words

I suppose it would be a competition of what is slower: searching for a single phrase without an index against searching for multiple words (or rather words that begin with ...) with index. And presumably the more words you have, the more likely the indexed search would be expected to win. But I am not sure how one would go about constructing a test that would substantiate these speculations with a meaningful result.

 

[comment]

6 hours ago, Craig_ST said:

good to know there are other ways

Not "other". Better. You seem very determined to ignore this point - but this is a public forum, so for the benefit of anyone else reading this I will stress it once again.