top of page

SearchResults 7

Search

It's a key FileMaker feature, and used heavily in every solution –

but the feature set hasn't seen much love in a long time.

​

The solution? SearchResults.

It's a free tool easily added, and has one killer feature: It searches many tables in your database, and shows you results on one page. It's fast, easy to customize, and all JSON.

Story of search:

fmSearchResults was written by Matt Navarre after hundreds of hours of pondering search in FileMaker. After researching, testing, and refining, it was released. Each new version brought features, such as name substitution, data entry correction (for date fields) tooltips, QuickFind control, and more. 

It boils down to this: FileMaker does some things very very fast. If you can take advantage of these, and do them serially with changes each time, you can get amazing results. 

This knowledge implied one key idea:

Take advantage of what FileMaker does well

and repeat it for different types of searches and in different tables.

What is FileMaker really great at?

  • Searching an indexed field in the local table

    • Especially with a relatively small found set

  • Finding no matching records

    • (this feature can be a good thing... read on)

  • Running complex script code quickly

  • Running scripts on the server (local access to data)

  • Deploy the same code on FileMaker Pro, Go, WebDirect, etc.

What is FileMaker bad at?

  • Intelligent single field search (think Google, or Bing. Or even Lycos)

  • Search in a related table of any kind (and your database is normalized, so this is important)

  • Searching unindexed fields

  • Displaying a list of results from more than one table (we aren't talking about a portal here)

  • Displaying a list of records with a large found set

  • The Quickfind feature (It's affected by all of the limitations above)

  • Knowing what you are looking for before you do a search

How SearchResults works:

  1. User enters a search string (into a global field)

  2. Determines what type of data the user entered (person's name, date, phone, currenty, range of data, text, etc)

  3. Looks only in the tables and fields where that type of data exists

  4. If no results are found, it loosens the criteria and searches again, and repeats until either records are found, or they aren't likely to exist.

  5. Continues through all the desired tables in your database

  6. Displays the combined results on one page

  7. In a database with millions of records and dozens of tables, it can do all of that in a fraction of a second.

​

While developing the latest release of fmSR, I had big goals to simplify and standardize the code. Enter JSON. There are two key areas that I'd like to show that rely on JSON:

• Storing, displaying and editing user preferences

• Building metadata through the scripts that do the search magic.

bottom of page