Hi. Forgive me if my terms and knowledge are limited. I'm an Intermediate Filemaker user.

I've experimented a bit with the built in FM Quick Find and it takes too long to find any matches in our solution. Maybe I haven't waited long enough, but the query goes on and on so I cancel the search. I've read the Seedcode site articles about Quick Find's pitfalls and those seem to apply to us entirely.

We're currently exploring FMSearch so as to have one integrated search feature in our database. We like the results display of FMSearch. There is live sql data throughout parts of our database. Currently many of our searches using standard Filemaker field level search must be exact matches when searching sql data or it returns no matches. How well does SR work with sql table data? Will it be able to find for example 12345 as a match to a sql field containing 00012345? This doesn't work for us using search directly in a field.

Looking forward to your reply.

Hi,

The Quick Find could be set to unindexed fields or related fields and this can really cause it to bog down. You can disable the fields individually, so checking which ones have the Quick Find on is a good way to speed up the native behavior.

FMSearch also uses FileMaker's built in Search Engine, so there shouldn't be a big difference in the performance, although the "searched" fields in FMSearch Results are more explicitly set than the Quick Find / Layout which tends to add all fields by default.

You can't index ESS/SQL fields within FileMaker, so searching on them is going to be slower than native FM ones, but having them "indexed" in SQL should help.

A standard FileMaker find will pick-up extra training characters but not leading ones, so 12345 won't find 00012345, but 00012 will. If you want to pick-up the leading characters, then you need to use the * wildcard character, so *12345 will pick-up 00012345. FMSearchResults just does standard searches by default, but modifying it to throw the leading * in there is certainly doable.

Hope that helps!
-Jason