Hoe je trage FileMaker scripts kunt vinden

Uw FileMaker-oplossing voelde ooit snel aan. Nu duurt een klik op een knop drie seconden, een nachtelijke import loopt door tot na middernacht, en gebruikers klagen voorzichtig dat "het systeem voelt traag" zonder dat iemand precies kan zeggen waarom. Het frustrerende is dat FileMaker je zelden vertelt welk script de schuldige is — het wordt gewoon... langzaam.

Dit artikel laat je precies zien hoe je het specifieke script (of de stap binnen een script) vindt dat je oplossing afremt, met tools die ingebouwd zijn in FileMaker plus enkele gewoonten die toekomstige vertraging veel gemakkelijker opvangen.

Waarom is het zo moeilijk om te zien welk script traag is?

Anders dan een webserver met request logs en response-time dashboards, vertelt een FileMaker-oplossing je niet automatisch "Script X duurde 4,2 seconden op dinsdag om 14:00." Traagheid wordt vaak door een gebruiker in vage termen gerapporteerd: "het openen van het factuurvenster is traag" of "de export duurt eeuwig nu." Die ene klacht kan veroorzaakt worden door:

• Een script met een niet-geïndexeerde zoekopdracht
• Een loop die waarden herberekent die dat niet hoeft te doen
• Een netwerkronde die eenmaal per record plaatsvindt in plaats van eenmaal per batch
• Een layout met te veel objecten, niet-opgeslagen berekeningen, of portals die bij opening laden
• Een trigger (OnRecordLoad, OnLayoutEnter) die stiekem zware logica op de achtergrond uitvoert

Dus de eerste taak is niet iets repareren — het is isoleren waar precies de tijd heen gaat.

Stap 1: Reproduceert de traagheid met een stopwatch, niet een gevoel

Voordat je een tool aanraakt, krijg je een echt getal. Laat de gebruiker (of jezelf) de exacte reeks klikken uitvoeren die traag voelt, en time het met een stopwatch op je telefoon. "Het is traag" wordt "het openen van de Order Detail layout met 40 regelitems duurt 6 seconden." Deze basislijn is belangrijk omdat je na optimalisatie moet aantonen dat het echt verbeterd is — niet alleen een gevoel dat het zo is.

Stap 2: Gebruik de Script Debugger om de uitvoering regel voor regel te controleren

Open de Script Debugger (Tools menu, in FileMaker Pro Advanced) en werk het verdachte script regel voor regel door. Let op:

• Stappen die merkbaar langer pauzeren dan andere wanneer je op Step Over drukt
• Loops die veel vaker itereren dan verwacht (voeg een tijdelijke variabele toe om iteraties te tellen)
• Geneste scriptoproepen (Perform Script) die andere scripts activeren die je helemaal vergeten was

Dit is traag en handmatig, maar het is de meest directe manier om een script te vangen dat iets onverwachts doet — bijvoorbeeld een script bedoeld om één record bij te werken dat per ongeluk door een hele gevonden set loopt omdat een Go to Record/Request/Page stap ontbreekt.

Stap 3: Gebruik de Data Viewer om specifieke expressies in te stellen

Het Watch-tabblad van de Data Viewer laat je berekeningen live evalueren terwijl een script draait. Als je vermoedt dat een bepaald berekeningsveld of ExecuteSQL oproep het knelpunt is, voeg het toe aan de Watch-lijst en zie hoe lang het duurt om tegen echte gegevens — niet testgegevens — te evalueren. Een berekening die instant is op 50 records kan echt tijd kosten op 50.000.

Stap 4: Instrumenteer het script zelf met tijdstempelvariabelen

Dit is de techniek die je het duidelijkste, meest betrouwbare antwoord geeft, en het werkt in zowel FileMaker Pro als server-side scripts (waar de Script Debugger niet kan reiken). Voeg deze regels toe rond verdachte secties:

Set Variable [ $start ; Get ( CurrentTimeUTCMilliseconds ) ]
# ... verdachte trage sectie ...
Set Variable [ $elapsed ; Get ( CurrentTimeUTCMilliseconds ) - $start ]

Log $elapsed naar een variabele, een tekstbestand (via Insert File / Get(DocumentsPath) export), of een speciale Log-tabel. Wikkel elk hoofdblok van een script — de zoekopdracht, de loop, de export, de commit — in zijn eigen start/stop paar. Voer het eenmaal uit, en je hebt een tabel met: zoekopdracht = 40ms, loop = 4.800ms, export = 90ms. Nu weet je precies waar je op moet focussen.

Voor oplossingen met terugkerende prestatievragen is het de moeite waard om een kleine permanente loggingtabel te bouwen die script naam, stap, duur, gebruiker en timestamp bij elke run boven een drempel (zeg, 1 seconde) registreert. Dit verandert "het systeem voelt soms traag" in een dataset die je echt kunt bevragen en over tijd kunt volgen.

[[IMAGE:left|een script met tijdstempelpunten die één trage sectie onthullen]]

Stap 5: Controleer FileMaker Server-side, niet alleen client-side

Als het script draait als een Server Schedule of via Data API/OData, zullen geen van de bovenstaande client-side tools het rechtstreeks vangen. In plaats daarvan:

• Controleer het Server Stats log in FileMaker Server Admin Console op verstreken tijd per scriptplanning
• Schakel het Topcall / slow query logging in dat beschikbaar is in FileMaker Server's Database Server instellingen, wat elke query logt die langer duurt dan een door jou ingestelde duur
• Controleer de Client Statistics in Admin Console tijdens de trage bewerking om te zien of het CPU-gebonden, I/O-gebonden, of wachtend op netwerkronde-trips is

Een script dat goed draait op een snel kantoornetwerk kan pijnlijk traag worden voor een externe gebruiker op VPN — hetzelfde script, dezelfde gegevens, een volledig ander knelpunt (netwerklatentie per ronde-trip, niet de scriptlogica zelf).

Wat zijn de meest voorkomende oorzaken eenmaal je het trage gedeelte hebt gevonden?

• Niet-geïndexeerde zoekopdrachten — een zoekopdracht op een niet-opgeslagen berekeningsveld dwingt FileMaker om elk record te evalueren in plaats van een index te gebruiken. Reparatie: sla de berekening op, of zoek in plaats daarvan op een geïndexeerd veld.
• Loops met een Set Field in plaats van een batch replace — het updaten van 10.000 records één tegelijk in een loop is veel langzamer dan een Replace Field Contents of een goed geformuleerd script met Get(FoundCount) controles.
• Onnodige Commit Record stappen in een loop — elke commit is een ronde-trip naar de server. Commit eenmaal, aan het einde, indien mogelijk.
• Portals en niet-opgeslagen berekeningen op layouts die gegevens laden die de gebruiker nooit scrollt om te zien. Het sorteren van een portal op een niet-opgeslagen berekening is een klassieke stille vertraging.
• ExecuteSQL query's zonder juiste indexering of uitgevoerd tegen tabellen veel groter dan de ontwikkelaar oorspronkelijk testte.
• Gekoppelde scripts die scripts oproepen die scripts oproepen, elk met zijn eigen overhead, wanneer één geconsolideerd script dezelfde taak met minder heen-en-weer zou doen.

Als je verschillende van deze patronen over dezelfde oplossing ziet, is het vaak een teken van diepere structurele schuld in plaats van één slecht script — dat is het bredere onderwerp dat wordt behandeld in onze gids over hoe je de prestaties en structuur van een FileMaker-oplossing kunt verbeteren.

Kan AI helpen trage scripts sneller te vinden?

Ja, steeds meer. Claris' eigen AI-assistent, Klai, kan door scripts lezen en inefficiënte patronen markeren — zoals loops die kunnen worden vervangen door een Replace Field Contents, of zoekopdrachten op niet-geïndexeerde velden — veel sneller dan handmatig door honderden regels stappen. Het zal het loggen van tijdstempels op je werkelijke productiegegevens niet vervangen, maar het is een nuttig eerste voorbijgaan om voor de hand liggende anti-patronen op te vangen voordat je zelfs de Debugger opent, vooral in oplossingen die jaren onder meerdere ontwikkelaars zijn gegroeid.

Layout-gerelateerde traagheid is een apart maar gerelateerd probleem: tools zoals FMBetterForms laten je lichtere, web-vriendelijke layouts bouwen die de objecttellijkheid en renderingoverhead reduceren waarmee FileMaker Pro soms worstelt op complexe formulieren, wat een layout sneller kan maken zelfs voordat je een enkel script aanraakt.

Een snelle checklist voor het zoeken naar een traag script

1. Time de trage actie met een stopwatch en noteer de exacte stappen die worden ondernomen
2. Identificeer welke script(s) während die actie draait (gebruik Script Debugger of een Log-tabel)
3. Voeg tijdstempelpunten toe rond elk hoofdblok van het script
4. Voer het uit tegen realistische (niet test) gegevensvolumes
5. Controleer of het client-side of server-side is, en test beide van een lokale en externe verbinding
6. Kijk naar de gebruikelijke verdachten: niet-opgeslagen berekeningen, loops met per-record commits, niet-geïndexeerde zoekopdrachten, gekoppelde scripts
7. Repareer één ding tegelijk en meet opnieuw — verander niet vijf dingen tegelijk en hoop

Veelgestelde vragen

Heeft FileMaker een ingebouwde performance profiler? Niet echt een speciale, maar de Script Debugger, Data Viewer, en Server's Client/Stats logs samen dekken het meeste wat een profiler zou geven — je hoeft alleen maar zelf het plaatje in elkaar te zetten.

Waarom draait een script snel voor mij maar traag voor een collega? Meestal netwerklatentie (externe vs lokale verbinding), een veel groter gevonden set aan hun kant, of een privilege set die extra validatieberekeningen dwingt te evalueren.

Moet ik scripts proactief optimaliseren of alleen wanneer gebruikers klagen? Een lichte loggingtabel die elk scriptrun boven 1–2 seconden markeert is het bouwen waard proactief in elke oplossing met meer dan een handvol gebruikers — het vangt vertragingen op voordat ze klachten worden.

Is een traag script altijd een scriptingprobleem? Nee. Het is vaak een schemaprobleem (ontbrekende index, niet-opgeslagen berekening) of een layout probleem (te veel objecten, onnodige portals laden) dat alleen naar voren komt wanneer een script dat veld of die layout aanraakt.

Het vinden van een traag script is uiteindelijk een diagnoseoefening, geen gissingsspel — en de bovenstaande gewoonten (tijdstempeling, realistische gegevensvolumes, server-side apart controleren) gelden of de oplossing drie jaar oud of vijftien jaar oud is. Als uw team steeds dezelfde prestatiemade zonder een duidelijke manier om ze op te sporen, of als een diagnostische doorgaan onthult dat het echte probleem diepere structurele schuld is in plaats van één slecht script, kan Loggix helpen — of dat nu een praktische performanceaudit, het herbouwen van specifieke modules met een schonere FileMaker-architectuur, of het introduceren van AI-ondersteunde tooling in uw dagelijkse ontwikkelingswerkstroom betekent.