fmSearchResults


Search within FileMaker: analyzed perhaps more than is healthy

 

Although fmSearchResults is commercial product, the purpose of this session is not to sell it, but to help you fully understand it if you already have it, to look at the underpinnings, and to discuss extending the use of search within your solutions

 

Primary topics:

1. What search problems need to be solved, and how best to solve them

2. Displaying results in a useful and interesting way

3. Optimizing for speed

4. Gathering results from multiple tables

5. Ranking results

 

Searching Google is great because the first page of results usually has what you're looking for. How can you get that mojo working in your FileMaker solution? First, searches must be REALLY fast, so users can try several serial searches. Next, they must be accurate, and often this means ranking (not just sorting)

 

To start with ranking, some records are more valuable than others because of how often they are accessed. Consider two companies in your customer database: John Smitherton, and Smithson Industries. John has never placed an order, but Smithson is your biggest client. Do a search for 'Smith' and sort the results by company name and John will (incorrectly) rank first. Add an Interface-side UID-linked table with a solution-wide stored view count, and you'll get better results. This is easier to implement than it sounds, and will be demonstrated.

 

Next, some records in a search match the search term more exactly, but you can't really sort on this. Consider these records:

Smithson Industries

Robert Smith

John Smitherton

If you did a search for 'Smith' all of these records would be found, but only one contains the entire word you entered, with no more, which might rank it higher. Since it's really hard to sort on a match like this, we'll discuss some potential solutions. If you did a search for ==Smith, it would be very slow for a large set of records, so a looping script that operates on a small set of records is my preferred method.