Level: Advanced, Version: FM 12 or later

Radical Separation, part 4

Disclaimer: This article contains speculative and experimental techniques that are in the proof-of-concept stage. Use at your own risk and test thoroughly.

FYI: In March at the Portland PauseOnError un-conference, Matt Navarre and I had a freewheeling Separation Model discussion, a podcast of which has just been posted as episode 85 at FileMaker Talk.

Welcome to the fourth and final installment in our series on Radical Separation. Today’s article assumes familiarity with part 1, part 2 & part 3, and continues in the direction we were headed at the end of part 3. Specifically, we will finish up our exploration of “virtual calculations” by examing an intriguing approach suggested by Barry Isakson to a) reduce the field count, b) solve the “define more fields than you’ll ever need” problem, and c) accommodate summary fields, and I invite you to follow along in today’s demo file, Virtual Calculations, Part 4, if you are so inclined.

6-9-2013 4-10-10 PM

Continue reading “Radical Separation, part 4”

Level: Advanced, Version: FM 12 or later

Radical Separation, part 3

Disclaimer: This article contains speculative and experimental techniques that are in the proof-of-concept stage. Use at your own risk and test thoroughly.

Today we’re going to delve further into the concept of virtual calculations, picking up where we left off last time, and with the assumption that readers are familiar with the material in part 1 and part 2 . We’ll look at some ways to make this technique less brittle (prone to breakage if objects are renamed), and also less opaque to DDR analysis tools such as BaseElements and Inspector. We’ll also see if the technique can be applied to auto-enter calc fields, and finally, we’ll explore some ways to make the technique easier to implement.

5-10-2013 10-41-51 AM

Demo Files:

Continue reading “Radical Separation, part 3”

Level: Advanced, Version: FM 12 or later

Radical Separation, part 2

Disclaimer: This article contains speculative and experimental techniques that are in the proof-of-concept stage. Use at your own risk and test thoroughly.

In part 1 of this series, we defined radical separation as a separation model scenario in which the developer no longer has access to a data file once a solution had been deployed. Updates to the solution are delivered in the standard separation model manner: by swapping in a new interface file.

We explored the concept of “virtual calculations”, where certain (unstored) calculated fields in a data file derive their definitions from syntax stored as data in a special table in the interface file. The advantage of this being that calculation logic can be redefined programatically by the simple expedient of replacing the interface file.

5-2-2013 9-09 PM

In the six weeks that have gone by since I posted part 1, I have made a couple improvements to the technique, one of which which we’ll examine in today’s demo file: Virtual Calcs, Part 2

Continue reading “Radical Separation, part 2”

ExecuteSQL, Level: Advanced, SQL, Version: FM 12 or later

Radical Separation, part 1

Disclaimer: This article contains speculative and experimental techniques that are in the proof-of-concept stage. Use at your own risk and test thoroughly.

Earlier this month I had the honor and the privilege to do a presentation on the topic of Radical Separation at the PauseOnError un-conference in Portland, Oregon, which included a demo file resembling this one: virtual-calcs-part-1-v2

3-20-2013 2-54-43 PM

Before the conference I posted a pseudo-F.A.Q. which included the following…

  • Q. What’s your experience with the Separation Model?
    A. I’ve used it heavily over the last seven years, for a variety of vertical market applications, custom projects and, recently, on a vertical market FMGo app.
  • Continue reading “Radical Separation, part 1”
Level: Intermediate, Version: FM 9 or later

User-Friendly Excel Exports, part 3

27 Mar 2017: see User-Friendly Excel Exports, part 6 for an updated approach.

So far in this series we’ve been looking at exporting data to Excel from a single table (Contacts). Today we’re going to extend the technique to encompass a second related table, Donations, and without too much trouble we can leverage existing work from earlier entries in this series (part 1, part 1.1 and part 2).

To avoid unnecessary repetition, this article assumes familiarity with the aforementioned predecessors, and you can follow along in today’s accompanying demo file, excel exports, part 3, if you are so inclined.

Continue reading “User-Friendly Excel Exports, part 3”

Level: Intermediate, Version: FM 9 or later

User-Friendly Excel Exports, part 2

27 Mar 2017: see User-Friendly Excel Exports, part 6 for an updated approach.

[Note: To avoid a huge amount of redundant repetition, this article assumes that you are familiar with part 1 and part 1.1 in this series.]

Today we’re going to take a look at streamlining the approach introduced in part 1 by reducing clutter on the Relationships Graph, going from this…

…to this, with no loss in functionality.

…and you can follow along in today’s demo file, excel exports, part 2, if you are so inclined. Continue reading “User-Friendly Excel Exports, part 2”

Level: Intermediate, Version: FM 9 or later

User-Friendly Excel Exports, part 1.1

Bruce Robertson emailed me off list with an improved version of my demo from part 1, excel exports, part 1.1, which I am sharing with his permission. The improvements are…

a) live preview fields showing the data to be exported.

b) an “Eval Error Tester” script to make sure the output code in the alias table is well-formed.

Thank you Bruce for making this available.

Level: Intermediate, Version: FM 9 or later

User-Friendly Excel Exports, part 1

27 Mar 2017: see User-Friendly Excel Exports, part 6 for an updated approach.

Many end users appreciate FileMaker’s ability to export a found set of records in Excel format — it’s fast, straight-forward and empowering. One request that I have received from clients multiple times over the years is: make the exported field names in the top row of the spreadsheet “human-friendly”…

For example, instead of this:

…perhaps they would rather see this:

Another request has been to allow data from multiple source fields to be combined into single export columns, as per columns A and C here:

And a third request has been to provide an interface so that users can pick and choose fields to export, including (where appropriate) related fields, without having to navigate the complexity of the native FileMaker export dialog. Continue reading “User-Friendly Excel Exports, part 1”

Level: Intermediate

Dynamic Variable Instantiation

28 Dec 2020: for further thoughts on this subject see Set Variable By Name Revisited.

6 Apr 2016: A “SetVarByName” custom function can make things a whole lot easier. For details, see Set Variable by Name.

31 Oct 2014: This was originally embedded inside another article, but I now realize it should have been a standalone post, so I am belatedly taking corrective action and making it so.

Although FileMaker provides a “Set Field By Name” script step, it does not provide a direct method to dynamically declare the name of a variable.

dvi

Note that I said there isn’t a “direct” method to accomplish this… but it can be done indirectly.

Creating Variables on the Fly

There’s something cool and slightly miraculous about being able to dynamically name and populate variables at runtime. In the code below we don’t care about $x at all — it’s just a convenient way to access the calculation engine so we can invoke the Evaluate and Let functions.

We’ll come back to that in a minute, but first let’s consider a much simpler example. If we know the name of the variable we want to declare, but want to specify the repetition dynamically, it can be accomplished in a very straight-forward manner, like so:

non-dynamic variable instantiation

This gives us a variable named $array_01[x] where “x” represents whatever number is currently in the $rep variable.

The following also achieves the same result, but normally we wouldn’t bother since it’s more work with no additional benefit. But it does show that a variable can be defined via Let, with the rep specified dynamically — in this example, via a variable, $rep, but Get(RecordNumber) or any calculated expression would work.

However, the technique breaks down if we try to dynamically specify the name of the variable itself. In the above example, we’re telling FileMaker to define a variable named $array_01 with whatever repetition number happens to be sitting in the $rep variable.

But we want to declare a variable named $array_xx where “xx” could be anything from “00” to “12” and is based on the value sitting in the $column variable (padded with a leading zero where appropriate), and to pull that off we need to bring out the heavy artillery, i.e., Evaluate.

It makes my head hurt, but it actually works.