Category: ExecuteSQL

ExecuteSQL, SQL

FM 12 ExecuteSQL “Unconference” Session

Kevin Frank

11 Sep 2012: The ConditionalVL_SQL demo has been updated to fix a minor bug.

Yesterday I had the pleasure of co-presenting a DevCon “Unconference” session with John Ahn on the topic of ExecuteSQL. I wasn’t sure if there would be much interest in this somewhat geeky subject, but the room was packed, and the audience ran the gamut from SQL newbies to SQL power users.

We started out with a basic intro, and showed a few simple demos. Next we moved on to a discussion of some of the issues, nuances, gotchas, etc. Then John showed a couple ExecuteSQL-powered demos which I strongly commend to your attention: a) Multi-Column Dynamic Portal Sorting…

…and b) Dynamic Value Lists…

…which, incidentally, caused every jaw in the room to drop, due to the fact that John’s method of constructing these conditional value lists seems to violate at least one fundamental law of FileMaker physics — more on this in an upcoming posting.

Here are links to everything we referred to during the presentation, in roughly chronological order.

FileMaker Hacks postings:

John Ahn’s demos:

Other links:

ExecuteSQL, Level: Intermediate, SQL, Version: FM 10 or later

Dwindling Value Lists, part 1

Kevin Frank

A few months ago I mentioned “dwindling value lists” in passing, and said I would do a proper article on them at some point in the future. Well, then FM 12 was released and I went on an ExecuteSQL binge, so I’m just now getting around to honoring my promise.

Dwindling Value Lists (DVLs) are value lists that shrink up, by removing individual list items as they are selected. They can come in very handy when you need to schedule resources and want to prevent double booking. This example comes from one of today’s demo files, Dwindling Value Lists, and shows how a DVL might be used to schedule employees for a work shift.

Essentially, a DVL is a filtered value list that updates in real time (or something very close to real time), and this is done by building a multiline key of selected values, and then filtering the VL to only show remaining eligible values. Continue reading “Dwindling Value Lists, part 1” →

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

FM 12 ExecuteSQL: Robust Coding, part 2

Kevin Frank

In part 1, I listed six scenarios that could potentially cause ExecuteSQL code to break:

…and managed to get through the first five before running out of steam. This time, we’re going to examine #6 on the list, and then look at a few miscellaneous odds ’n’ ends, and today’s demo file is ExecuteSQL Sandbox, v2, if you’d like to follow along.

Changing a Field Type

Why would changing a field’s type cause a problem? Well, first off, as I mentioned last month, if you are using that particular field as a predicate in a JOIN, the query will break, and your reward will be the the dreaded “?”.

I don’t have a fix for this, just some advice: Don’t change a field’s type if you’ve used it as a JOIN predicate in a working SQL statement. (The only reason I’ve needed to change a field type recently was to fix a broken JOIN where the field types were mismatched.)

Continue reading “FM 12 ExecuteSQL: Robust Coding, part 2” →

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

FM 12 ExecuteSQL: Robust Coding, part 1

Kevin Frank

[Note: Some of the material in this article, and in today’s demo file ExecuteSQL Sandbox, previously appeared in my March 2011 article, Custom Functions for Internal SQL.]

The other day a colleague remarked, “You know, it’s going to be interesting to see if you SQL guys are still so excited about ExecuteSQL when something gets renamed and your code breaks.” He had a good point: code is “brittle” if it works initially, but then subsequently breaks as a result of a seemingly innocuous action.

Here are some things that can cause ExecuteSQL code to break:

  1. Renaming a table occurrence (TO)
  2. Renaming a field
  3. Using a “reserved word” as a field or TO name
  4. Having a problematic character in a field or TO name
  5. Executing the code in a foreign country (!)
  6. Changing a field’s type (e.g., from text to number or vice versa)

…and today we’re going to look at some defensive measures we can employ to prevent problems when these things occur.

Using the “orders” table in the demo file…

Continue reading “FM 12 ExecuteSQL: Robust Coding, part 1” →

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

FM 12 ExecuteSQL: Dynamic Parameters, pt 2

Kevin Frank

This is a quick follow-up to part 1, with a couple more observations about dynamic parameters.

Embedded Apostrophes

Here’s one I can’t believe I forgot to mention the other day:  A major ExecuteSQL headache that dynamic parameters can alleviate is the dreaded “embedded apostrophe” problem. In case you aren’t familiar with it, if your text string contains an embedded apostrophe, in standard SQL you must escape it by prepending another apostrophe, for example compare these two “standard” (non-dynamic) queries:

As you might expect, you don’t have to worry about this if you instead use a dynamic parameter… just quote the search term the way you would any FileMaker text string (i.e., in double quotes) and go about your business.

Continue reading “FM 12 ExecuteSQL: Dynamic Parameters, pt 2” →

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

FM 12 ExecuteSQL: Dynamic Parameters, pt 1

Kevin Frank

I have a confession: when I first read about dynamic parameters in the Help entry for ExecuteSQL, my initial reaction was, “Why do they have to make it so darn complicated?”

I have another confession: I am now singing a very different tune. I’ll get to the reason for this in a minute, but first let’s compare two ExecuteSQL statements, which were discussed last month in FM 12 ExecuteSQL, part 1.

Continue reading “FM 12 ExecuteSQL: Dynamic Parameters, pt 1” →

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

FM 12 ExecuteSQL: A Cool Tool

Kevin Frank

It’s been a fun week experimenting with the ExecuteSQL function, and also seeing what others are doing with it. In some cases the experience has been eye opening, and I strongly recommend that anyone interested in ExecuteSQL grab the SQL Builder file from Eden Morris, available on FMForums (registration required) at http://fmforums.com/forum/files/file/25-sql-builder/

This attractive and powerful tool provides a point and click interface to build complex SQL queries, which are then rendered in FileMaker 12 ExecuteSQL syntax, e.g.,

The current version is 0.4, implying that updates may be forthcoming, so you might want to not only download the demo, but bookmark the above link as well. Very nicely done, Mr. Morris!

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

FM 12 ExecuteSQL, part 2

Kevin Frank

One of the fun things about a new FileMaker release is figuring out how new features work, including subtle behavioral nuances. Today’s demo file, FM12 ExecuteSQL Help Example from CW, is based on Corn Walker’s re-working of one of the demos from part 1, and helps demonstrate how ExecuteSQL fits in with the FileMaker security model.

Continue reading “FM 12 ExecuteSQL, part 2” →

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

FM 12 ExecuteSQL, part 1

Kevin Frank

FileMaker 12 offers many intriguing new features, including new windowing capabilities, significant charting and container field improvements, and a brand new design surface. But to my way of thinking, all of these pale in comparison to the exciting possibilities offered by the new ExecuteSQL function.

What’s so great about ExecuteSQL? In a nutshell, it allows us to natively (without a plug-in) perform queries against FileMaker tables using SQL (structured query language). This means that we can now write code to answer questions that previously required adding new table occurrences and special-purpose fields to serve as relational predicates.

Incidentally, if you’re curious about SQL in general, here are some good starting points:

And of course you’ll want to grab a copy of the FileMaker 12 ODBC/JDBC Guide, which offers tantalizing glimpses of what FileMaker is capable of SQL-wise under the hood. Much of the information in Chapter 7 is directly relevant to the ExecuteSQL function.

Continue reading “FM 12 ExecuteSQL, part 1” →