Yikes, it has been awhile since I've blogged here. As they say, fatherhood turns your priorities upside down, and for the better. Well, I am back, and there has been a ton of exciting activity from the our secret research labs at Proof to talk about.

We'll be unwrapping some great stuff for schools in the near future. Be sure to stay tuned or drop us a note if you are curious.

I went out to the Phoenix FMPUG meeting last week to give a quick talk about FileMaker's SQL API with the Phoenix FMPug group. Thanks, Audrey, for being such a great host! We had a lively discussion that evening and I even left with a few newly acquired nuggets of knowledge courtesy of the always generous Geoff Coffey.

You can grab slides from the presentation below but since my Keynote decks tends to be terse, I am not sure they would be all that useful by itself. So, here's a quick 'libretto':

I have been evangelizing the internal SQL API for FileMaker for some time now and I pretty much think it is one of the most important innovations on the platform. Sure, it is not as sexy as all the cool productivity features we have been getting in the recent releases of FileMaker Pro, but in terms of developer productivity, the SQL API is a pure powerboost.

I am talking about the INTERNAL FileMaker SQL API. No, you can't get to it with ScriptMaker or with a FileMaker's native calculation functions out of the box. To unlock the power of SQL, you need to install one of the many SQL plugins (see slides). These plugins expose the underlying SQL engine to you as an external function.

SQL is a structured way of talking to your database. If you are new to SQL, don't think of SQL as a new programming language, rather think of it as programmable way to define your FileMaker 'relationships'. It is sort of like writing calculated relationships (which we cannot really do at the moment).

Why use SQL?

FileMaker developers are spoilt. We get a lot for "free", but sometimes, there is no way to get to the data you want without either duplicating data in your 'downstream' tables or to create gnarly relationship graphs. SQL lets you write powerful expressions to replace complex relational graph gymnastics. SQL is cleaner.

It is also more flexible in that you can create joins you cannot do natively through the relationship graph. For example, you cannot do 'OR' multi-predicate joins on the graph. With SQL, that is trivial two letter word.

It is more powerful in many situations. In particular, since you can create, retrieve, update or delete records without a FileMaker context, you are free to perform database operations without off-screen windows or flipping layouts.

I find that SQL is ultimately easier for complex data-operations. But it is also easier in that SQL is expressed as text which can be stored and read semantically. The FileMaker relational graph locks your intent in a picture, and you can't change that intent without redrawing the graph. Whereas, you can dynamically create SQL to change the nature of query.

I'll be posting more SQL tips in the future.

 In the meantime, from all of us at Proof to you and your family, Happy Thanksgiving!