ISO FileMaker Magazine

Oh the pain of a slow rendering layout! The other day I came across a painfully slow layout which was literally CRAWLING. It reminded me of one of my own situations where I needed to create a solution for some type of creative data input. This, of course, was based on FileMaker's input limitations between two types of fields.

The choice of using a Drop-down list over a Pop-up menu field style was based on the type of input being managed. I didn't want the forced interaction of having to click, as is the case with a Pop-up menu. I also didn't want the whole menu of options, which were a lot, covering the whole screen. I liked the shortened option list presented with a Drop-down list.

I didn't, however, like the fact that a Drop-down list allows the user to simply input arbitrary data. I HAD to have the user make a selection from the list and wanted the shorter Drop-down list presentation. So, I set about the task of addressing the biggest issue first.

That issue was that normalized data uses your primary and foreign keys (id values) and NOT what you typically want to display. You want to display the associated human-readable value. In FileMaker, this almost always requires the use of two layout elements. One to store the data and another to display the data. The trick was figuring out how to make the Drop-down list do this - and make it fast! Hence the solution you're going to be viewing and experiencing in this video and technique file.

Who doesn't want their software to perform as efficiently and as quickly as possible. Don't we always want things to go faster and work better?

Of course we do. The problem is, we don't always take the time to fully think out what is happening when we solve a problem. Sometimes, we just robot our way through the code we are creating because it's how we've always done it - and it's easy or faster.

Being an "efficiency nut", when it comes to code, is something I really enjoy. It represents the fact that you have a reduced amount of code to accomplish the same thing that previously had more. Less code means less to maintain. Less code can also mean more performant.

In this video, I walk through a recent example of showing how a particular solution could be simplified. It's an example that plays out in the software world many times over. Most importantly, it represents what is the compounding effects of not taking the time to think out the most efficient solution. If and easiest to maintain, fastest performing solution is what you're after, then you may find a tip or two within this video about Assessing Performance.

When your average knowledge worker starts developing with FileMaker Pro, there’s a lot of background and history which may be missing. Especially, when it comes to making certain decisions about schema. We’ve all been at that level at some point in the learning curve, and the process of reworking things is just par for the course.

The FileMaker environment makes it so easy to simply add a new calculated value. It’s even part of our mental processing. “Oh, I need to calculate this.”

The problem, however, with FileMaker’s simplicity can be its detriment to performance. It’s far too easy to sprinkle in unstored calculations all throughout your database systems.

In other database environments, the notion of an integrated calculation doesn’t even exist. The database is simply the storage part of the whole equation and may not offer much logic at all. You might have stored procedures, but these aren’t part and parcel with the whole environment like they are within FileMaker.

In this video, I go over some of the tools and tricks I use in order to evaluate the performance level of any given database. Using this knowledge helps you to create more efficient systems which will perform better as time goes by. Remember the saying “Less is more.”? It may benefit your database when it comes to fields and layouts.