The Ugly: When it is slow it can be extremely slow.The Good: ExecuteSQL() is blazingly fast.So here is the good, the bad and the ugly: I certainly wouldn’t want to see people avoid it. While participating in the online FileMaker forum, it struck me that ExecuteSQL() seems to be getting a bad reputation, and I do not think it deserves it. There are reserved SQL keywords that can clash with your field and table names.įor now, I want to focus on performance.ExecuteSQL() supports a particular subset of the SQL syntax it does not always support SQL syntax that you may be used to from other environments.Looking for “wim” will not return records where the value is “Wim”. The fact that SQL queries are case sensitive.Then there are subtle differences that can catch people out: If you need the ability to manipulate data, there are many FileMaker plugins that provide that capability.
The big obvious restriction is that ExecuteSQL() does SELECTS only, in other words: you use it to collect data, you cannot use it to create or update existing records. Don’t let the age of the blog post give you pause all of it is still very relevant if you are not so familiar with all the ins and outs of the function (and even serves as a refresher if you are familiar with the function). What Does ExecuteSQL() Do?įirst off, if you need to get up to speed on what ExecuteSQL() does and does not do, the best reference is this blog post by Kevin Frank and Beverly Voth. Ever since the ExecuteSQL() function was introduced in FileMaker Pro 12, there’s been much debate over its use and usefulness and its speed.