ISO FileMaker Magazine

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.