ISO FileMaker Magazine

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.

In the world of FileMaker solutions, it's almost inevitable that a solution will experience significant growth during the initial stages, followed by a transition to the everyday pace of normal use. When developing those initial features, one of your key objectives should be to emphasize reuse and repurposing. As is often the case, the less you have to manage, the easier it becomes to maintain and update your solution. There's less to re-learn, and your scripts, layouts, calculations, and other elements are more straightforward to locate and update.

However, if you tend to create numerous one-off duplicates within your code, you may end up with a collection of disparate elements that require attention or become obscured over time as additional features are added, potentially duplicating some earlier functionality. In complex solutions, it's not uncommon to become confused about what was implemented earlier and inadvertently replicate entire feature sets.

In such scenarios, you're left with the burden of either consolidation or selecting one implementation to retain while removing the others. A more effective approach is to proceed by making aspects of your solution universal and the default method for accessing specific functionality. This is where creating universal pickers that apply solution-wide can yield substantial benefits. In this video, we address precisely this situation and guide you on how to approach their implementation.