Using TO names instead of base table names
ExecuteSQL uses base table names, not Table Occurrence names. If your TO is Contacts_portal, the query must reference Contacts.
ExecuteSQL
Learn how ExecuteSQL works, fix common errors, and test queries instantly.
The Basics
ExecuteSQL allows SQL queries inside FileMaker calculations. Introduced in FileMaker 12, it is commonly used for reporting, aggregation, and faster data queries that bypass the relationship graph.
// Basic syntax
ExecuteSQL (
"SELECT name FROM customers WHERE id = ?" ;
"" ; // field separator
"" ; // row separator
customer_id // ? argument
)
Reference
| Parameter | Description |
|---|---|
| sqlQuery | SQL SELECT statement |
| fieldSeparator | Separator inserted between returned fields in each row |
| rowSeparator | Separator inserted between rows |
| arguments | Values substituted for ? placeholders in the query, in order |
Common Mistakes
ExecuteSQL uses base table names, not Table Occurrence names. If your TO is Contacts_portal, the query must reference Contacts.
String literals in FileMaker SQL must use single quotes inside the query string. Mixing up FileMaker's double-quote strings with SQL single-quote literals is a common source of errors.
Field names must match exactly as defined in the table — including case on some systems. Use LIMIT instead of FETCH FIRST n ROWS ONLY is another common field-adjacent mistake.
If your query contains ? placeholders, each one must have a corresponding argument passed after the rowSeparator, in order. A mismatch returns ?.
Examples
ExecuteSQL (
"SELECT COUNT(*) FROM Customers" ;
"" ;
""
)
ExecuteSQL (
"SELECT name FROM Customers
WHERE country = ?" ;
"" ;
"" ;
"USA"
)
ExecuteSQL (
"SELECT name, city FROM Customers" ;
" | " ; // field sep
¶ // row sep
)
Performance
ExecuteSQL can be faster for reporting, aggregate calculations, and cross-table queries where traditional relationships are slower or complex. Because it bypasses the relationship graph and runs directly against base tables, it avoids the overhead of TO chains and portal filtering — especially for COUNT, SUM, and multi-table JOIN queries.
Debugging
Test SQL queries outside FileMaker using FM Dojo's SQL Fiddle — it shows real error messages instead of ?
Verify you're using base table names, not Table Occurrence names
Check your field and row separators — an empty string is often the right choice for single-value results
Check parameter placeholders — every ? needs a corresponding argument passed after the rowSeparator
FAQ
A ? means the query failed. Common causes: using a Table Occurrence name instead of the base table name, a syntax error, an unsupported keyword like LIMIT, or a missing parameter placeholder. FM Dojo's SQL Fiddle shows the actual error message.
Empty results mean the query ran successfully but found no matching records. Check your WHERE clause conditions, verify field names are correct, and confirm the data you expect actually exists in the table.
No. ExecuteSQL queries base tables directly, bypassing the relationship graph. This makes it powerful for cross-table reporting and aggregates — but you must use base table names, not Table Occurrence names.
FM Dojo Toolkit
ExecuteSQL query validator
Test queries against a live SQLite sandbox before deploying.
FileMaker JSON tools
Build and validate JSONSetElement and JSONGetElement calls with AI.
FileMaker script builder
Write and export FileMaker scripts as native clipboard XML.
AI assistant for FileMaker
Ask anything about FileMaker — scripts, calculations, schema, relationships.
Test your query in FM Dojo's SQL Fiddle and get the actual error — not a question mark.
Test Your ExecuteSQL Query Free