Experiences of a FileMaker Pro Database Developer

FileMaker Server, Please Abort Cancelled Finds!

I’m usually not one that likes to rant or get on a soapbox. I find this unproductive and I’m not really sure it does much to contribute, plus I feel that most readers don’t like a complainer. However, there is one topic that I’m in a uproar over.

Whenever a user cancels a find using FileMaker Pro Client in a FileMaker Server hosted environment, FileMaker Server does not cancel and abort the find. No matter how long it takes, FileMaker Server is going to complete the find. Even if the client force quits or gets disconnected from the FileMaker Server. You cannot even use the FileMaker Server Admin Tool to “force” close the offending client. If you do, or if the client has force quitted FileMaker Pro client, they will still be visible under the Admin Tool under clients until the find is complete.

What makes this worse is how FileMaker Server works with multiprocessors, especially in a Windows Server environment (note: I have not tested this much on a Mac Server). FileMaker Server hands off specific tasks within a table to a free core. For example, if you have single processor dual core machine and you perform a find in table A, FileMaker Server is going to utilize one of the cores until it finishes the task. And, any other find request that comes in on Table A will be queued until the first Find is complete. It will not pass over the second request to the other core, even if it’s free. However, a different task or a Find taking place in a different table will utilize the second core.

So, if a user performs an unindexed find in Table A, they are going to bog down that entire table until the find is complete. When you are talking millions of records and Table A is a busy table with all users working in it and performing searches, this can have drastic results. Daily, I use a high-end server with 4 dual-core processors (8 cores), and I’ve flatlined (maxed out) one processor core with an unindexed find on a heavily used table and I brought the system to a grinding halt. I was using less than 5% of the processing power and the other 7 cores were free and ready to work.

I was doing a search in order to perform some maintenance routines on a set of records. Once I hit find, I knew I was in trouble. It was a mistake and I wanted to constrain the find on a smaller set of records, but I hit perform find instead. There was no way to cancel. I hung up the entire company. Two hours later, we were back up. Not fun!

Post to Twitter

Speak Your Mind