The Support Group Blog

As we discussed in our previous blog post, FileMaker has released a new feature set involving transactions. The new scripts allow us to send the changes we make to a record to the server in aggregate. So, we can batch all our changes together in one transaction and send that to the server. 

If you read our blog regularly, you might remember we created a test file to demonstrate a technique on how to create multiple records at one time. We can also use the new transaction scripts to accomplish this task. For example, instead of creating 10,000 records in a loop one at a time, thereby producing 10,000 individual transactions, we should be able to submit those 10,000 new records as a single transaction. 

Claris released a new version of FileMaker, and it’s pretty exciting. Of course, the usual list of bug fixes and minor enhancements to the platform accompanied the update. Nonetheless, there's at least one outstanding new feature: Transactions.  

In the database world, a transaction is any operation on an entity. In FileMaker world, it represents any change made to a record. Previously, we made most of our changes to our records, one record and one field at a time. And, when we clicked out of the field in FileMaker, it committed the record, thereby completing an operation for that entity - in other words, performing a transaction. This function helps keep all our data in sync with other users who concurrently access the database. But it can impede the performance of our system, especially in a wide area network (WAN) environment with poor network speed or high latency.  

There's always room for improvement and that certainly applies to custom app development. We've discussed some of the things to watch out for when designing our custom FileMaker apps, such as how to deploy them efficiently when we access FileMaker remotely and improve the performance of record creation and modification. Mitigating these bottlenecks alone can transform our trusty old commuter cars into the hot rods we've always dreamed of. But even the best-oiled machines might need some internal reengineering from time to time to continue humming down the road.

In the previous article, we chatted about speeding up record creation and modification within our FileMaker applications. As we said, there's no one size fits all way to make an exotic supercar out of a minivan. However, there are ways to make that minivan corner smoothly and stop quickly and maybe even take off from the line like a dragster.

In this article, we're going to focus on ways to mitigate bottlenecks when we access our FileMaker apps remotely. Due to the pandemic, many of our users are accessing hosted apps from home. Of course, we do this over the internet, also referred to as a Wide Area Network (WAN). When we connect to the network at the office, that is typically a Local Area Network (LAN), which usually offers faster speed than a WAN.

Claris FileMaker is an excellent tool for getting stuff done. It gives us lots of space and versatility, like a minivan that can take our kids to soccer practice and stow a ton of groceries from the local supermarket. Our FileMaker custom apps are just as multi-faceted. But when we inevitably store a lot of our data in those custom apps to leverage its powerful ability to solve all sorts of problems, the system can get kind of pokey. When FileMaker becomes our tool of choice for every challenge that we confront, chances are our system will start to show the strain of all this virtual responsibility. Let's discuss some strategies we can use to solve those pesky FileMaker performance issues. None of our suggestions will transform your daily driver into a race car; however, it may feel more like one.