Download a sample file here. 1MT_QuickFind.zip
Please share if you liked this post.
Released with FileMaker 11, more than 8 years ago in 2010, Quick Find is probably one of the most underestimated features in FileMaker.
For some reason, there wasn’t even much emphasis in the product marketing when it was released. Platform evengelists would mention it as a ‘Google-like search engine within FileMaker’, product documentation said ‘search in all fields of current layout’, but it was never said clearly how powerful this feature is.
And it is extremely powerful.
Here are a few things you should know before we come to the core of this blog post
But wait, didn’t I write that the power of Quick Find was underestimated? so where’s this power I was talking about?
Well, it’s simply the way Quick Find does search. Because we’ve had the classic Find mode and Perform Find script step for so long, many overlooked the Quick Find feature thinking it was just like a find, but on many fields at a time.
Say I have a Contact table with firstName, lastName, occupation, city, of which firstName is the only field not included in the Quick Find. And I’m looking for a plumber in Cincinatti. What you would do with the classic find is
In the old days, if one wanted to propose a ‘Google-like’ search (even before we’d heard of Google), he could add an indexed calculation field to the table like
city & " " & lastName & " " & occupation
and enter ‘plumber Cincinatti’ in find mode, and that’s because FileMaker considers individual words in the same field as criteria with an AND operator.
But with Quick Find, you don’t have to create this field because what Quick Find does is NOT
If it was this, then no records would be found because none of the fields contains the 2 words.
What Quick Find does just cannot be done with Perform Find. It takes each word and does all possible combinations. So with ‘plumber Cincinatti’, it takes the first word (plumber) and finds all records where one of the 3 fields contains ‘plumber’ and then among those, it finds all records where one of the 3 fields contains ‘Cincinatti’. This explanation has nothing to do with HOW it does it (the process is probably very different from this). I’m only trying to explain WHAT it does.
But the magic doesn’t stop here. This combinatory search also works with related records! So you can for instance search for ‘plumber Cincinatti approved supplier’ where ‘approved supplier’ is a value to be found in the related company table. The only thing you have to do is insert that field on the layout and make sure it’s included in the Quick Find.
In the attached sample file, you will see a search engine that gets results from multiple tables. In the old days, you would have had to draw complex relationships with a bunch of ≤ and ≥ criteria, calculated fields and all. Look now how simple it is to perform Quick Finds, get the results to a global field and display the result with a simple relationship.
I hope you learned something with this blog post. Please feel free to drop a line here under in the comments.
Thanks for this great reminder about this amazing tool!
Here’s a Quick Find tip that has worked well for me: When I want to use Quick Find, I create a dedicated layout just for the Quick Find. The user never sees this layout–it’s simply a place where I define which fields should be included in the Quick Find. This way I never need to be thinking about the implications for Quick Find when making interface modifications. Note: I never display the toolbars, so all Quick Finds are scripted. The user typically enters search criteria in a global field, then a script navigates to the Quick Find layout to perform the find, then goes to the appropriate layout to display the results.
Thank you for the post. I have started using quick find again recently (scripted), in combination with the “master-detail” portals.
We place the “current table” portal in a popover button, and call it “quick list”. We place just a couple of fields, the most relevant for identifying the records, and a global field on top of the portal that triggers the quick find as the user types (with a script trigger). Seems to save time to users, they like it.
I agree that it’s inconvenient that FM adds to the quick find fields that are added to the layout. Then we always have to remember to remove them … specially fields from related tables or unindexed, that can make the quick find a really “slow find”!
Bel article qui décrit bien la recherche rapide avec ses avantages et ses contraintes.
J’apprécie la solution de multiples recherches rapides qui contourne habilement la recherche sur des champs non indexés.