FileMaker 2025 is er, en hij spreekt eindelijk uw taal

Door Serhii Leschenko

Ongeveer een week geleden werd FileMaker 2025 gelanceerd, met een reek spannende nieuwe functies. Je vindt de volledige lijst in de officiële release-opmerkingen.

Net als de update van vorig jaar ligt de nadruk bij deze release op AI-mogelijkheden — allemaal ontworpen om het leven gemakkelijker te maken voor zowel ontwikkelaars als eindgebruikers.

Opmerking: we gebruiken in dit artikel de engelstalige namen voor scriptstappen en functies.

Vandaag duiken we in één opvallende functie: een nieuwe scriptstap genaamd:

Perform SQL Query by Natural Language

Waarom is dit zo spannend?

Heel simpel, deze functie laat je complexe queries uitvoeren zonder ingewikkelde scripts te schrijven, en zonder je zorgen te hoeven maken over context of gevonden sets.

Geen noodzaak om layouts te wisselen, globals te beheren of geneste relaties te bouwen enkel om een eenvoudig datapunt op te halen. Je kan nu gewoon vragen naar de data zoals je er zelf over denkt.

Laten we enkele voorbeelden bekijken die tonen hoe transformerend dit kan zijn.

Initiële setup

Begin met je AI-account te configureren en een algemene prompt te maken die wat syntactische context over je database geeft. Dat helpt de AI om je toekomstige verzoeken beter te begrijpen.

Configureer vervolgens de scriptstap zelf:

Een volledige uitleg van de opties vind je in de Claris-documentatie. Hier zijn enkele belangrijke instellingen voor dit voorbeeld:

• We gebruiken het GPT-4o model van OpenAI
• Prompt en respons worden opgeslagen in een globaal veld
• We gebruiken een prompttemplate die we eerder geconfigureerd hebben
• Alleen “anchor” TO’s zijn geselecteerd om te garanderen dat we steeds met volledige datasets werken
• We gebruiken het actietype “Query” voor een leesbare output.

Opmerking: ik schakelde een paar keer naar “Get SQL” tijdens het testen, gewoon om te zien hoe de queries geconstrueerd worden. Helaas is het niet mogelijk om beide tegelijk te gebruiken. Ik probeerde twee kopieën van de scriptstap na elkaar te plaatsen — één met “Query” en de andere met “Get SQL” — maar dat maakte het script erg traag. Iets om de volgende keer verder te onderzoeken.

Je kan de inhoud van elke testtabel hieronder bekijken. Je kan het bestand zelf ook onderaan deze pagina downloaden.

De basis testen

We beginnen met eenvoudige vragen voor de tabellen “Contacts” en “Addresses”:

• Hoeveel records zitten er in de tabel “Contacts”?
• Hoeveel adressen zijn er in Londen?
• Toon me de namen van mensen met de titel “Mr.”

Alles werkte perfect — niets revolutionairs. Dus laten we iets uitdagender proberen…

Vraag: “Hoeveel contacten wonen én werken in dezelfde stad?”

Screenshot 10

Het eerste resultaat was fout, maar door de bewoording aan te passen klopte het wel:

Om zeker te zijn dat we correcte resultaten krijgen, paste ik het werkadres van een paar contacten aan zodat het niet overeenkwam met het thuisadres — en inderdaad, de resultaten waren opnieuw correct. Een traditioneel script zou veel tijd gekost hebben — dit duurde minder dan 5 seconden.

Opmerking: we mogen natuurlijk niet vergeten dat we met een klein dataset werken hier.

Conclusie #1: Wees specifiek. AI heeft nog steeds duidelijke instructies nodig.

Andere voorbeelden:

• Slecht: “Hoeveel contacten werken in Londen?”
• Goed: “Hoeveel contacten hebben een werkadres in Londen?”
• Goed: “Toon de namen van contacten met een werkadres en een thuisadres in verschillende steden. Toon ook de steden van hun adressen.”

Queries op ongerelateerde tabellen

Ik weet wat sommigen van jullie nu denken: “Oké, Serhii, maar hoe is dit anders dan andere AI-zoekopties? We zoeken nog steeds in dezelfde tabel!”. En dat is een terechte opmerking. We voerden onze aanvragen uit vanuit de context van de contactentabel en we zochten in een gerelateerde tabel, niets speciaals.

Dus laten we het wat spannender maken.

Maak kennis met de “Movies”-tabel. Die werd later hernoemd naar “RandomName”, maar daar gaan we nu nog niet op vooruitlopen. Doe maar alsof die nog steeds “Movies” heet.

Kunnen we ook queries doen op die totaal ongerelateerde tabel? Ja, dat kan! Zoals je ziet, doen we een aanvraag vanuit dezelfde context als daarvoor en krijgen we een correct resultaat:

Ik deed nog een paar basisqueries om te bevestigen dat alles goed werkt, maar we slaan die saaie over.

Lastige queries

Mijn volgende uitdaging voor onze kleine helper was: “Hoeveel films werden geproduceerd in Europese landen?”

En het werkte niet. Wat begrijpelijk is, want er is niets in onze database dat een land koppelt aan het mysterieuze “Europa”. Toch wilde ik het nog een kans geven, dus herformuleerde ik de vraag:

“Hoeveel films werden geproduceerd in landen van de Europese Unie?” — verrassend genoeg werkte dat wel!

Dit verbaasde én verwarde me tegelijk. Verbaasd omdat het blijkbaar extra info ophaalt om uit te zoeken wat de “Europese Unie” is en welke landen daar bij horen. Verward omdat het dat niet van de eerste keer deed.

Ik stelde de vraag nog enkele keren. Soms een correct resultaat, soms “Geen data beschikbaar voor antwoord”. Geen duidelijk patroon zichtbaar.

Na deze ontdekking besloot ik terug te keren naar een eerdere test: zoeken op land.

Er zijn films uit landen zoals de VS en het VK. Als ik vroeg naar films uit “USA”, werkte het. Maar als ik vroeg naar “US”, kwam er niets. Oplossing: “Hoeveel bands komen uit de VS? Doe een onnauwkeurige zoekopdracht.” — en toen werkte het wel.

Maar wat als iemand een totaal andere naam gebruikt? Zoals “VK” of “Groot-Brittannië”? Ik vroeg het, en kreeg meteen het juiste antwoord:

Maar ook hier weer: herhaal het een paar keer en de resultaten worden inconsistent.

Conclusie #2: Controleer altijd op consistentie. De AI herhaalt resultaten niet altijd betrouwbaar als je vraag concepten bevat die niet expliciet in je database zitten.

Aliasnamen & hernoemde tabellen

Tijdens het testen vroeg ik me af: hoe weet AI eigenlijk naar welke tabel ik verwijs? Gebruikt het TO-namen? Basistabelnamen? Wat als ik die hernoem?

Ik hernoemde mijn TO van Movies naar Cinema. Geen probleem. Dan van Cinema naar XYZ — nog steeds oké. Tot slot ook de basistabel naar RandomName — werkte nog steeds.

“Oké,” dacht ik, “zo slim kan het toch niet zijn.” Dus maakte ik een vierde tabel, UnknownTable, met een TO genaamd ABC. Geen vorige naam, geen evidente velden. Deze tabel bevat gegevens over muziekgroepen — zou AI dat kunnen raden?

Ik vroeg: “Hoeveel bands komen uit USA? Doe een onnauwkeurige zoekopdracht.” En jawel:

Hoe het dat wist? Geen idee. Misschien was het veld Genre een hint. Of houdt het gewoon van muziek.

Contextvrije queries

Als het zo slim is, laten we dan vragen zonder enige context stellen. Enkele resultaten:

• “Toon alle unieke genres.” — werkte direct
• “Wanneer is Nirvana opgericht?” — correct (1987)
• “Wanneer is Nirvana gemaakt?” — geen antwoord
• “Waar komt AC/DC vandaan?” — correct (Australië)
• “Toon Engelse bands.” – geen resultaat
• “Toon Engelse bands. Probeer andere bekende namen voor het land.” – toonde bands uit VK; herhalen gaf wisselende resultaten
• “Toon rockbands.” — faalde
• “Toon bands die rock spelen.” — werkte prima
• “Toon bands die metal spelen.” — zelfde als bij rock
• “Hoeveel bands hebben genre metal?” — gaf 0 terug, omdat AI toen precieze zoekopdracht deed

De interessantste: “Welk land heeft de meeste films?” en “Welk land heeft de meeste contacten?” — beide correct. Maar “Welk land heeft de meeste bands?”:

Herinnering: tabel ABC bevat bands, XYZ bevat films. AI kent dus het concept “band”, maar raakt soms in de war.

Andere test: “Toon alle unieke namen.” — gaf soms namen uit alle relevante tabellen terug, soms niet. Inconsistentie, afhankelijk van welke velden exact “Name” heetten.

Een heel nuttige prompt

“Can you give me the IDs of all the records from the table [tableName] where [some condition]? The output must only contain the IDs in a list format, do not include any text.”

Geeft een mooie lijst met ID’s — ideaal voor de nieuwe scriptstap “Ga naar lijst van records”.

Laatste notities

In sommige gevallen maken deze natuurlijke taal-queries automatisch indexen aan voor velden met “automatisch indexeren indien nodig” aangevinkt. Maar ik zie nog geen duidelijk patroon.

Voorbeeld: “Toon bands die opgericht zijn in 1994” maakte een index aan op “Founded”.
Voorbeeld: “Wanneer is Nirvana opgericht?” deed dat niet.

Meer testen zijn nodig dus.

Dat was het! Heb je iets bijzonders ontdekt over deze nieuwe scriptstap, of wil je een correctie doorgeven? Stuur gerust een mailtje naar serhii.leshchenko@clickworks.eu.

Tot ziens!