ISO FileMaker Magazine

FileMaker solutions don't really care where your data comes from. They've long had the ability to reach out into ODBC & SQL sources of data. So long as the connection is fast and stable, users really don't know, or care, where the data is hosted.

With the addition of Claris Studio, data can even be hosted within a NoSQL database such as MongoDB - although we can't, as of yet, structure any of the data other than through the Claris Studio interface.

This also means you can use the same External Data Sources feature to split up your single solution into as many files as desired. It's a perfect tool for segmenting out complex systems such that smaller sub-systems are both accessible but separate. This allows you to plan for more variety in the use of your technology and apply better security protocols.

Even when you get to the level of simply separating a single FileMaker solution into two files of UI and Data, you'll find some benefits. If your data file is a separately hosted file, then your UI file can also be hosted or optionally local to the device the user is using. This video provides a How-To of converting a single FileMaker file into the Data Separation model. While there are few gotchas with a simple solution, it's beneficial to know how to troubleshoot a more complex conversion. Of course, starting out with a Data Separation mindset can be beneficial as well.

In Part 2 of our exploration of Smart Solution Architecture, we delve into the fascinating aspects of structuring your FileMaker solution. While the 'common' method of structuring a FileMaker solution might be the simplest, it doesn't necessarily guarantee optimal performance.

As the development of your solution evolves, increased complexity naturally accumulates a few 'cobwebs' and you may encounter potential slowdowns. In order to avoid or diminish this, you'll want to be aware of all the possiblities.

If your goal is to craft a solution that seamlessly blends aesthetics, performance, and ease of maintenance, the FileMaker development environment offers a wealth of possibilities to tap into. The good news is that it's not only entirely achievable but can also be an enjoyable endeavor. This video guides you through additional options for structuring your solution. The exciting part is that FileMaker's ability to facilitate communication between files, regardless of their location, and the indifference of FileMaker's Relationship Graph to data location, empower you to design highly creative solutions.

Give this video a watch if you aim to explore the variety of ways you can create a solution which leverages all of FileMaker's advantages while sidestepping some of its shortcomings.

FileMaker development is an exhilarating journey which empowers you with the ability to have complete control over the data you want to manage and manipulate. Yet, at times, it can be a test of patience as you strive to achieve the desired results - especially as you're learning. The good news is that, in the vast majority of cases, what you aim to accomplish is not only feasible but likely easier (and faster) to accomplish than in many other development environments.

Although I may be a bit biased, I can unequivocally affirm that FileMaker's environment frequently delivers outcomes that go beyond mere acceptability for your software requirements. The challenge with FileMaker lies in its legacy, which may not be immediately evident or well-understood when you embark on your journey with it. Discovering resources like these videos help to gain insights into how choosing one solution architecture path over another can yield specific consequences.

What's fortunate is that FileMaker development offers the flexibility to rectify even the most misguided decisions regarding your data presentation. While shifting your data structure into a different format can be somewhat more complex, wrapping a new user interface around your existing data can be quite straightforward. This first video in a two-part series aims to present various options and methods for crafting intelligent solution architecture when building your application within Claris FileMaker.

One of the best parts of learning to develop within FileMaker is you have a great sense of "full control" over the data you want to manage. This applies to situations even as simple as a hobby or something you enjoy. In fact, these "hobby databases" are some of the best ways to expand your learning about how to both structure and present data. If you haven't before, you should give yourself a challenge with something you enjoy!

In this video, I decided to break down the series of steps I took while simply creating a game tracking database for managing a hobby sport of mine. Pickleball is a fast-growing sport which seemingly sits right between tennis and table tennis (ping pong). I wanted my own solution to manage some games and decided to take a few hours to create the needed structure. Yeah, there's software out there, but I really like that "full control" feeling.

The solution developed quickly and I saved versions of the file as I went along. The benefit of your time investment in this video is, hopefully, a good explanation of how to approach the process of structuring and presenting your data. Along the way you may pickup some useful tips which may help your current and future database systems.

Being in need of a new database system myself, I decided to simply document the process of adding new features to a FileMaker system as it evolves. This is a great way to learn about the ins-n-outs of what goes on when developing a new system. There's a number of things which may or may not make sense when you take a look into how someone else created something. So, why not make videos as the solution progresses.

In this first video, I showcase how I originally started the file and where I should start to plan for a larger solution. There's a bit more needed than simply just throwing some fields into a table. There are also a number of settings and defaults which are created by FileMaker.

This video talks about those default elements, how to deal with them and how to start planning for an easy-to-maintain database solution.

One of the more troublesome questions we ask ourselves as developers is "Am I doing this the right way?". And, while it applies to most all situations, it most certainly applies to data structure.

If you don't structure your data well enough, then you either have to restructure it later, and migrate, or try to solve some of your problems in very odd ways.

Fortunately, the variety of ways you can actually store data presents a lot of options depending on what type of software you need to create. The key is knowing these different ways and choosing one which sets your solution up for success.

All software, over time, becomes outdated. It's like thinking things are all good living in a house built in the early 1900's when everything around you has gained significant improvements. The same applies to software. There are newer and newer ways of doing things. In this video, we take a look at three primary ways of breaking down structured data. We classify the student/teacher subtype as it applies to a person. If choosing how to store your data has always been a tricky question for you then you should find some peace of mind with this particular video.

Continuing on with the two part series about Narrow vs. Wide tables, this video will go into how to best filter your data, especially if you have a large amount. It will present the data within the structure we'd created within the first video.

Knowing the impact of data operations isn't just limited to the structure of your tables. It's also about how much data is loaded and shown to the user based on what the user needs to see. If you have a relationship resulting in hundreds of thousands of possible records, it doesn't really make sense to show anything other than what the user really needs to see.

If the user only needs to see 3 months of data then simply load the three months and allow the UI to provide options to adjust. That's exactly what we cover within this video. Let's learn how to limit what is shown within your narrow table structure.

Like any good craftsperson, you should know your tools and your methods for accomplishing things in the most efficient and best performing way. This is always most obvious when it comes to that every slowing FileMaker solution which started out innocently as a simple "helper" database. Then... it ended up being used for all kinds of things. Critical things even!

It was thrown together based on how you mentally "see" the data and not how the data should have been structured. This is one of those painful lessons where you have to go in and retrofit the data to a new structure or make plans to migrate to an updated solution.

In this video, I discuss the ever important topic of Narrow vs. Wide tables. It's a common problem in a large number of FileMaker solutions. I know because I've seen tables with field counts within the thousands. This just shouldn't be the case. FileMaker is an all-or-nothing data solution when it comes to records. If you have 1,000 fields, then FileMaker will give you all the data from all 1,000 fields. This is unlike SQL, where you only return the data you specifically ask for. With FileMaker, you have to plan your solution's data management much more carefully! Watch this video for a better understanding of how to make your tables more narrow.

Having worked with FileMaker for well over 20+ years, and experiencing a wide variety of data models, it's always possible to get into a situation where you need to re-evaluate the data decisions you've made with regards to your structure.

The data model you may have initially thought would handle all situations may need to be modified. Knowing about the multiple options you may have available for structuring your data makes a big difference when you start to consider simply "adding that new field" to your database.

It may be that the workflow or process required would cause duplication of data and therefore increase the complexity of your solution unnecessarily. In this video, I cover the topic of a Single Source of Truth for storing field data. While the topic isn't limited specifically to fields, and should be considered for tables and data overall, it's good to know how to deal with specific cases where storing data becomes a big concern when dealing with additions, updates and deletions. Be prepared to learn more about strategic ways to store data in this video about Single Source of Truth.

While creating videos on my YouTube channel for my beginner/intermediate series of videos, a viewer asked if I would create a video about migrating from using Serial values as primary/foreign keys to using UUID key values.

The process is actually quite simple, but not so obvious when you start thinking about all the scripting you might have to do for all the various tables and connections within your solution. The benefits of switching to a UUID key based system is that you no longer have worry about duplicates with disconnected files and you also gain the piece of mind that you don't have to worry about updating the serial value every time you perform an export/import process for updating a database which is not updated directly within production.

So, in this video, I show the easiest method for moving from using serial key values to using the more modern UUID values. If you have an older FileMaker system and you'd like to update it to UUID keys, then this video should have all the info you need.