We are sorry, information on this page is available only in Czech. Use Translator Switch to Czech

Pause On Error Portland 2014 Recording

by HOnza Koudelka

Pause On Error Portland 2014 Recording - Preview Image

After participating on Pause[x]London 2011 and Pause[x]Berlin 2013 I got invited to attend Pause On Error Portland 2014 as well. Even though my schedule did not allow me to attend in person, I managed to host one session about Efficient Optimizing and Troubleshooting of FileMaker Solutions and Business Processes remotely over Skype. Now, few years later, the content seems to be still very relevant…

So, whether you could not attend Pause On Error 2014, or if you attended but want to recall some specific details, now you can watch the recording of my session here, or at least read a brief summary of the most important points below.


Just like my few previous conference sessions, I wanted to share my experience with optimizations. As part of it I also talked about the most common optimization mistakes. But one of the greatest things I discovered was that in addition to optimizations, the tool I used helped me and my team even more with troubleshooting.

A relatively unrelated case study from a New York City restaurant shows how common it is to incorrectly think that the cause of an inefficiency or bad performance is something else than what the real cause is.


When finding out why customers complained about slow service, by analyzing CCTV recordings the restaurant discovered their staff was performing still the same for 10 years, but the guests behavior changed with the rise of smartphones.

It has been proven many times that the most efficient way to optimize a FileMaker solution (or anything else) is to collect objective data, then identify the real bottleneck, optimize only that bottleneck, and then repeat the same process again.


The nice thing I discovered in 2014 is that while collecting data necessary for identifying bottlenecks, we also at the same time collect valuable data that can be used for troubleshooting. And we troubleshoot a lot more often than optimize.

Without using this collected data, troubleshooting can be very inefficient mostly because most users are only rarely able to accurately tell us what exactly they were doing prior to facing the issue we’re trying to troubleshoot.

When we have the data, however, we don’t have to rely on users because we can simply look at the log and see not only what a specific user was doing at what time, but also what other users were doing at the same time, which can help as well.

The fact that I can use the data collected by FM Bench not only for optimizations, but also for troubleshooting, was probably my most valuable discovery of the year 2014 and I was glad to be able to share it with Pause On Error attendees, so that even other people can benefit from it. So I hope sharing the recap here will help even more people.

Call us Call

+420 608 301 880

Usually available on working days between 7am and 5pm GMT

We'll call you back if you call from a discoverable phone number and fail to reach us

Let us call you Let us
call you

By completing and sending the form you agree that 24U s.r.o., a company established under the laws of the Czech Republic, with its registered office: Zvole u Prahy, Skochovická 88, CZ-25245, registered in the Commercial Register with the Municipal Court in Prague, section C, inset 74920 will use your personal data contained in the form for the purpose of sending 24U’s news, updates and other commercial communications. Providing 24U with personal data for the said purpose is optional. Details on personal data processing and on your rights connected therewith are contained in 24U’s Privacy Policy.

Loader Image