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.

Coding software solutions offers the fascinating realization that there are always multiple pathways to achieve the same goal. Sometimes the methods we're familiar with may not be the most optimal, prompting us to expand our knowledge to explore alternative approaches.

This video explores precisely that theme - the comparison between older and newer methods of accomplishing the same task. The advantage lies in the fact that newer methods often come with additional features or benefits. This is particularly true when it comes to obtaining the current record data as a JSON object. Historically, we've relied on ExecuteSQL to extract field names and values from the current record or a set of records.

In this video, I delve into the existing options using ExecuteSQL for creating a JSON object of the current record data. This method is effective in various scenarios. However, accessing related data can be time-consuming, especially when constructing SQL joins accurately requires significant mental effort. Unless you're a SQL expert, this may not be the most efficient use of your development time. Fortunately, recent versions of FileMaker have streamlined the process, making it exceptionally easy, with an alternative method, to extract any data from any record and convert it into the precise JSON object needed for passing parameters or interacting with external APIs.

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.

When embarking on your journey with FileMaker, you encounter the wonderfully visual tool known as the Relationship Graph, which grants you the ability to visually comprehend the intricate interconnections within a complex solution. In fact, the relationships used to link table occurrences in FileMaker are fundamentally akin to those in SQL.

FileMaker essentially offers a visual representation of what would otherwise be a textual definition of a SQL statement. The key distinction lies in the fact that SQL operates within the realm of text and only executes when required. Conversely, the Relationship Graph in FileMaker is persistent and is continually assessed by FileMaker. Consequently, comprehending the implications of specific relationships in your solution becomes vital as your solution expands. Relationships that appear ostensibly simple, serving utility purposes within your user interface, might have more profound ramifications than you initially realize. Hence, it is imperative to comprehend and effectively employ all of your available tools.

One of these indispensable tools is FileMaker's full SQL implementation. In this video, I delve into the advanced aspects of using SQL within FileMaker. If you've constructed your FileMaker solution exclusively using native FileMaker features, you might unknowingly incur a big cost if you haven't invested time in learning FileMaker's SQL capabilities.