ISO FileMaker Magazine

JSON, JSON, JSON! If you haven't gotten used to it yet, you'd better start. It's the way you communicate with the web. It's the structure that's winning. XML is too verbose, and .tab and .csv aren't always clear enough.

So, what are some of the ways you can create JSON within FileMaker? Here are just a few:

1. Create a calculated field of it.
2. Use ExecuteSQL() to return it.
3. Use Execute FileMaker Data API [ ].
4. Write a looping script.
5. Or... you can just export it.

This last method is often the most optimal for getting your data into the JSON format to meet whatever requirements you may have. You can further modify this JSON using a variety of tools to achieve the perfect result.

In this video, and the associated technique file, I provide the knowledge and code necessary to simply export your data as JSON and be done with it. No matter what you need and where you need it, you can use multiple exports from however many tables desired to end up with the needed JSON result.

If there's one thing you shouldn't ignore from the start of any FileMaker solution, it's the way security is going to factor into your creation. You need to know who the users and groups are and what their access rights are. These access rights are called privilege sets within FileMaker.

All too often, security may be an afterthought because most of the fun typically lies in creating solutions to the problems. The real trick is to create the solution to the problem while simultaneously considering how security wraps around that problem.

Unfortunately, with FileMaker being such a flexible platform, testing those access rights is not obviously easy. We have one simple way of testing one privilege set versus another: logging out of the system and then logging back in as another user. This process, while critical, can seem like a hassle, so it's often deferred. With the information in the associated video and technique file, you'll enjoy learning about a very easy-to-use system that allows for testing things quite easily. The solution simply takes advantage of part of how FileMaker works after the authentication process. Need to up your security game within FileMaker? You're sure to find some answers within this solution.

Over one's development career, you'll come across a number of people who "think" they know how something really works. You then proceed to show them some of the cool things they can really do, like a "context jump" within FileMaker. You then smile at their surprise, because what they thought was possible isn't even the start of it.

If you don't even know about, or truly understand, FileMaker's ability to jump from one context to another, then you're missing a critical piece to the FileMaker puzzle. It's one of the ways you break down a complex solution into a more digestible division of smaller parts. This not only makes the Relationship Graph potentially more understandable, but may make your solution more performant.

There are, however, a few big issues you must address as your FileMaker solution becomes more and more complex. One of these is protecting your code against itself. Certain script steps like Delete Record, Delete All Records and Replace Field Contents can have severe consequences. Especially, if performed without confirmation. And even then, accidental clicks is certainly a thing! In order feel really comfortable about using these types of actions you can always "protect" your code from doing the wrong thing in the wrong place. This where you implement either Layout or Context specific checking. This can easily be done when you know how to use FileMaker's internal ID values.

Spreadsheets really suck!... Long live spreadsheets, they're super useful! This simple contradiction, however, is likely a part of our technological lives for the rest of time. Unless AI removes the need for people to directly interact with data, spreadsheets are likely here to stay. And, for good reason. They're actually super useful!

As a software/database developer you need to realize that not everyone intuitively understands the solution you've created. In fact, the learning curve, may just be too painful - at least relative to what they may already know. Most users will tend to default to what they feel comfortable with. In the not so distant past, managing data was actually just words on paper. In fact, there's a word you're probably familiar with, it's 'list' - a very common development term. Yep, we still use lists.

Did you notice that? I referenced the fact that you're developing software and you can't really create software WITHOUT using lists. So, why not simply accommodate users' needs to simply default to using a spreadsheet. You just need a simple way to get the data in and out of your solution. Fortunately, this has all been solved by the tab and comma characters. If your users are using a lot of spreadsheets, then enjoy this video article and the associated technique file as we work with the MBS plug-in's super powerful Matrix.* suite of functions for some super functionality. Let's just Copy/Paste that spreadsheet data into a virtual spreadsheet and manipulate the data to fit our needs.