I speculate that filemaker is having to build the indexes from scratch to get rid of the <no access> records which takes more time.
OS version? FMP version (Server?)? Local access or WAN (same router, outside local network)?
Optimizing is discussed in several sites. LinkedIn has a group - Optimizing Filemaker
A Google for "slow finds on large databases filemaker"
Solving Performance Emergencies with FileMaker Server
A Google for "optimize filemaker"
FileMaker Script Execution Time Cut From 5 Hours To 6 Seconds
Thanks to both of you. I'm on a Windows 7 machine running FMP Adv 12 and the Server is running 12 Adv at a hosted site.
I'm checking out the articles now.
Any find you perform will automatically omit any records from which the current user is not permitted access. This could indeed slow them down due to evaluating the "lock" expression on each and every found record to see if they should be omitted from the found set.
So is there another, better way to restrict access? Maybe with a script and custom buttons that always includes the restricted parameters to every search?
Not something I can really answer from the info in this thread. I'g go with record level access control if at all possible. You might examine the lock expression you are using to see if there is a way to make it a more efficient calculation.
If you have to avoid RLA to get the response times that you want, you might set up a search layout with global fields for specifying criteria and a search button that uses that criteria to perform the find. Then the script can include a constrain step that filters out the records they aren't permitted to see.
But I'd examine that lock expression for issues first as the "filter out the no access records" process that takes place with every find really shouldn't result in a dramatic increase in response time as it should use much the same methodology as I've spelled out for this find script...
OK, oddly enough I just created a new privilige set with (actually a duplicate of another) and the only thing I changed is limiting the view of the records to equal a single geographic district (dist = 208). Now everything works like a charm - and fast. I don't even get the <no access> on records. Wierd.
Any find performed--either via script or by the user should automatically omit all "no access" records from the found set. Once a find has been performed, the only way your user should be able to get no access records in view is if they use Show All Records or Show Omitted Only. And if you have FileMaker Advanced, you can set up a custom menu that either removes these options from the Records menu or replaces them with scripts that do a Show All or Show Omitted operation, but which then filter the found set to omit the no access records.
Yes, this does seem to be the best solution.
Do you have any ideas on an opening script that will perform the find for 200 districts without making 200 separate "IF" statements in the script?
Modify this script to use your tableoccurrence::FIeld names. The key thing is that you can use any field in your table in place of YourTable::PrimaryKey so long as it is indexed and never empty in any record in your table.
Enter Find mode 
Set FIeld [YourTable::PrimaryKey ; "*"]
Set Error Capture [on]
I'll give that a try.