The Support Group Blog

One common request we often receive as FileMaker developers is to give users the ability to export the data out of the FileMaker app into Excel. While FileMaker provides the ability to do this quite easily with the tools built into the app, users often want more flexibility and customization when it comes to the formatting of the exported Excel sheet. 

There are a variety of options that are available here – plugins exist to make this possible, and we have a blog post that outlines a routine way to export custom headers from FileMaker using XSLT sheets. But we can also export data from FileMaker to Excel with the power of JavaScript.  

One remarkable thing about working in a supportive and dynamic collective like the FileMaker developer community is that we can share our experiences and techniques. With Claris FileMaker, there are often many solutions to any given problem, and over time our community has come up with some innovative and creative ways to use FileMaker. Unfortunately, these things are usually not found in the standard documentation, but developers share them among themselves. Here are three compelling tips and techniques that we discovered recently. 

TL;DR: Use the import function instead of a loop to create many records simultaneously. 

In FileMaker Land, it happens that, on occasion, we have to create many records in one fell swoop. For example, when a new cohort of students enrolls at a school, we have to make a bunch of records in a student database. Or, a retailer would need to add new seasonal stock items to its inventory database over the course of the year.

We all know FileMaker is a great platform to store, organize, and find data, be it grandma's recipes or the inventory of a multinational corporation. Most avid FileMaker users can figure out how to enter, delete, search, and even create lists of stuff with little to no help. The one thing that we often struggle with is reporting on all this data. We know that FileMaker is super powerful in this regard, having seen examples of its reporting prowess everywhere, from the Internet to personal experiences using solutions designed by others. But how to do it exactly often eludes us.

More often than not, we initially store our data in a spreadsheet. We then transfer the data from the spreadsheet to FileMaker in the hopes of expanding functionality. A spreadsheet, at its core, is a different beast. A spreadsheet is a static grid with a very intuitive but sometimes limiting method of summarizing data. For example, we can easily total the data to the left, right, top, or bottom of our “Sum” cell in a spreadsheet. This rigid grid makes it easy to count our data because of its inflexibility. This rigidity is also why most of us ultimately move most, if not all, of our data-driven workflows into FileMaker. FileMaker allows us to structure the interface and data the way we want instead of being forced to use some arbitrary grid. But, we soon find out that FileMaker's ability to organize the data the way we want comes at a price; this price is the complexity of reporting.

Since very early in its life FileMaker (perhaps even before it was FileMaker Pro) could store binary data (zeros and ones). We have all kept things like pictures, movies, and eventually portable document formats (PDFs), Word documents, and even object linking and embedding (OLE) files on Windows. If you can store it in a file, you can put it in a container field. As FileMaker evolved over the years and embraced new technology trends, such as QuickTime and Adobe's PDF format, the container field capabilities have expanded to integrate the latest file trends with our data-driven workflows. Let's explore some of the fundamental parts of setting up and using container fields.

Container fields act very much like the other types of data storing fields, including text, number, date, time, timestamp, etc., except we can't search, sort, or use them as a key in a relationship. However, we can set them up to be stored globally, targeted in scripts, and utilized in calculations and the results of calculations. The one thing that container fields feature that other "data" fields don't is the option to store themselves externally.

One of the main reasons we use FileMaker is because it saves us time and makes entering data accurately and consistently a breeze. The key to making FileMaker our data entry go-to tool of choice is mastery of the Auto-Enter tab in the Options for Field dialog box.

When we create a new field or edit an existing one in the Manage Database window, we have the opportunity to modify the field's setting via the Options for Field dialog box. There are four tabs in the Options for Field dialog, and we're going to focus on the first one, Auto-Enter. This tab lays out all the options we have for allowing FileMaker to enter or even modify our data along with us as we enter it. However, the option we're interested in for this post is the calculated value. The calculated value option is very flexible and allows us to do many things that the other options allow and more.

With all the recent ransomware events in the news, it's clear that we need to protect our servers and apps from eyes and ears that aren't our own. To that end, let's review some of the ways bad actors find ways to access our FileMaker data. We'll also highlight the FileMaker cyber security features that Claris provides to help us defend ourselves against attacks.

Before we get started, let's explain what ransomware is. A ransomware attack occurs when a hacker hijacks a data source and then requires payment before they'll release it. In the age of cryptocurrency, this type of cyber threat is easily facilitated because of the exchange's inherent anonymity and virtual impregnability. Unfortunately, the Colonial Pipeline outcome is an exception, not the rule. Therefore, it's improbable that there will be little to no financial consequence in a ransomware attack.

To that end, we, as keepers of personal and sensitive data, need to do our best to protect it. There are some very sophisticated techniques out there to secure our databases. Claris recognizes this and offers several defense features for non-technical and highly technical users alike.

Claris introduced a new feature in version 18 of the FileMaker Platform called Save a Copy as XML. You can find this command within the Tools menu if you have the "use advanced tools" option enabled in the FileMaker desktop application's Preferences section. With this menu command, Claris gives us a window into each of our custom apps' inner workings, as well as a way to more easily document even the most complex ones.

Extensible Markup Language (XML) is a web development tool used to store and transport data. Like HTML, which is a markup language for data presentation, XML requires opening and closing tags. XML is useful for FileMaker development because it facilitates the exchange of data between two systems. However, we can also use it to parse or read our data. In this article, we'll explore how we can protect the integrity of our FileMaker applications as we scale and evolve them.

In a previous article, we chatted about FileMaker error codes and made a point to emphasize the importance of keeping our eyes open during development. We have to be ever vigilant within the obscure areas of our solutions where things might break. Sometimes, we have to push our solutions to the brink in the hopes of revealing a weakness that may have otherwise gone unnoticed. We also took a look at a few techniques for trapping errors and then organizing them so that we can deal with them appropriately. This post will explore a new tool that Claris gave us a few versions back called Set Error Logging. This tool allows us to take error trapping to a whole new height.

The Claris FileMaker Platform makes it easy for us to develop functional custom applications. We can move data from repeating fields and manage and customize images in FileMaker applications. It's also relatively easy for us to identify errors, but we have to know how to organize and interpret FileMaker error codes. If we learn when and how to leverage specific tools that FileMaker provides to troubleshoot bugs within our apps, we can avoid issues and frustrations down the line.

Identifying and capturing errors within our FileMaker applications are an essential part of the development process and it can feel a bit like a roller coaster ride. When we create an app that makes our jobs easier, we want to make sure that it does the right things effectively and reliably. That's why having a solid understanding of the potential error codes we might encounter and how to resolve them successfully is so important. In this post, we'll deal with the highs and lows of fool-proofing our FileMaker apps by maneuvering through conventional errors and exploring some common places where bugs tend to crop up.