[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fxatFEl1RzILfYBCRRDuAA2LlkcDP52h7hliL4T2S0DQ":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":24,"hasDownload":25,"fileName":26,"youtubeId":27,"domainCrumb":28,"clusterCrumb":31},"375","F5A3F4E1-E62B-8B43-BAB2-92BE763CC770","E46BDB0A-2979-1E40-93F7-AC40185848A5","B11BED08-2F4E-4C45-9373-6175FA721411","article","how-to-find-slow-filemaker-scripts","Hoe je trage FileMaker scripts kunt vinden","Een praktische gids voor het diagnosticeren van welke FileMaker scripts uw oplossing vertragen, met stap-voor-stap benchmarkmethoden en veelvoorkomende oorzaken.","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.\n\nDit 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.\n\n## Waarom is het zo moeilijk om te zien welk script traag is?\n\nAnders 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:\n\n- Een script met een niet-geïndexeerde zoekopdracht\n- Een loop die waarden herberekent die dat niet hoeft te doen\n- Een netwerkronde die eenmaal per record plaatsvindt in plaats van eenmaal per batch\n- Een layout met te veel objecten, niet-opgeslagen berekeningen, of portals die bij opening laden\n- Een trigger (OnRecordLoad, OnLayoutEnter) die stiekem zware logica op de achtergrond uitvoert\n\nDus de eerste taak is niet iets repareren — het is isoleren waar precies de tijd heen gaat.\n\n## Stap 1: Reproduceert de traagheid met een stopwatch, niet een gevoel\n\nVoordat 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.\n\n## Stap 2: Gebruik de Script Debugger om de uitvoering regel voor regel te controleren\n\nOpen de Script Debugger (Tools menu, in FileMaker Pro Advanced) en werk het verdachte script regel voor regel door. Let op:\n\n- Stappen die merkbaar langer pauzeren dan andere wanneer je op Step Over drukt\n- Loops die veel vaker itereren dan verwacht (voeg een tijdelijke variabele toe om iteraties te tellen)\n- Geneste scriptoproepen (Perform Script) die andere scripts activeren die je helemaal vergeten was\n\nDit 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\u002FRequest\u002FPage** stap ontbreekt.\n\n## Stap 3: Gebruik de Data Viewer om specifieke expressies in te stellen\n\nHet 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.\n\n## Stap 4: Instrumenteer het script zelf met tijdstempelvariabelen\n\nDit 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:\n\n```\nSet Variable [ $start ; Get ( CurrentTimeUTCMilliseconds ) ]\n# ... verdachte trage sectie ...\nSet Variable [ $elapsed ; Get ( CurrentTimeUTCMilliseconds ) - $start ]\n```\n\nLog `$elapsed` naar een variabele, een tekstbestand (via Insert File \u002F 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\u002Fstop 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.\n\nVoor 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.\n\n[[IMAGE:left|een script met tijdstempelpunten die één trage sectie onthullen]]\n\n## Stap 5: Controleer FileMaker Server-side, niet alleen client-side\n\nAls het script draait als een Server Schedule of via Data API\u002FOData, zullen geen van de bovenstaande client-side tools het rechtstreeks vangen. In plaats daarvan:\n\n- Controleer het **Server Stats log** in FileMaker Server Admin Console op verstreken tijd per scriptplanning\n- Schakel het **Topcall \u002F 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\n- Controleer de **Client Statistics** in Admin Console tijdens de trage bewerking om te zien of het CPU-gebonden, I\u002FO-gebonden, of wachtend op netwerkronde-trips is\n\nEen 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).\n\n## Wat zijn de meest voorkomende oorzaken eenmaal je het trage gedeelte hebt gevonden?\n\n- **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.\n- **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.\n- **Onnodige Commit Record stappen in een loop** — elke commit is een ronde-trip naar de server. Commit eenmaal, aan het einde, indien mogelijk.\n- **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.\n- **`ExecuteSQL` query's zonder juiste indexering** of uitgevoerd tegen tabellen veel groter dan de ontwikkelaar oorspronkelijk testte.\n- **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.\n\nAls 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](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution).\n\n## Kan AI helpen trage scripts sneller te vinden?\n\nJa, 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.\n\nLayout-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.\n\n## Een snelle checklist voor het zoeken naar een traag script\n\n1. Time de trage actie met een stopwatch en noteer de exacte stappen die worden ondernomen\n2. Identificeer welke script(s) während die actie draait (gebruik Script Debugger of een Log-tabel)\n3. Voeg tijdstempelpunten toe rond elk hoofdblok van het script\n4. Voer het uit tegen realistische (niet test) gegevensvolumes\n5. Controleer of het client-side of server-side is, en test beide van een lokale en externe verbinding\n6. Kijk naar de gebruikelijke verdachten: niet-opgeslagen berekeningen, loops met per-record commits, niet-geïndexeerde zoekopdrachten, gekoppelde scripts\n7. Repareer één ding tegelijk en meet opnieuw — verander niet vijf dingen tegelijk en hoop\n\n## Veelgestelde vragen\n\n**Heeft FileMaker een ingebouwde performance profiler?**\nNiet echt een speciale, maar de Script Debugger, Data Viewer, en Server's Client\u002FStats logs samen dekken het meeste wat een profiler zou geven — je hoeft alleen maar zelf het plaatje in elkaar te zetten.\n\n**Waarom draait een script snel voor mij maar traag voor een collega?**\nMeestal netwerklatentie (externe vs lokale verbinding), een veel groter gevonden set aan hun kant, of een privilege set die extra validatieberekeningen dwingt te evalueren.\n\n**Moet ik scripts proactief optimaliseren of alleen wanneer gebruikers klagen?**\nEen 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.\n\n**Is een traag script altijd een scriptingprobleem?**\nNee. 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.\n\nHet 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.","\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>Waarom is het zo moeilijk om te zien welk script traag is?\u003C\u002Fh2>\n\u003Cp>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:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Een script met een niet-geïndexeerde zoekopdracht\u003C\u002Fli>\n\u003Cli>Een loop die waarden herberekent die dat niet hoeft te doen\u003C\u002Fli>\n\u003Cli>Een netwerkronde die eenmaal per record plaatsvindt in plaats van eenmaal per batch\u003C\u002Fli>\n\u003Cli>Een layout met te veel objecten, niet-opgeslagen berekeningen, of portals die bij opening laden\u003C\u002Fli>\n\u003Cli>Een trigger (OnRecordLoad, OnLayoutEnter) die stiekem zware logica op de achtergrond uitvoert\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Dus de eerste taak is niet iets repareren — het is isoleren waar precies de tijd heen gaat.\u003C\u002Fp>\n\u003Ch2>Stap 1: Reproduceert de traagheid met een stopwatch, niet een gevoel\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2>Stap 2: Gebruik de Script Debugger om de uitvoering regel voor regel te controleren\u003C\u002Fh2>\n\u003Cp>Open de Script Debugger (Tools menu, in FileMaker Pro Advanced) en werk het verdachte script regel voor regel door. Let op:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Stappen die merkbaar langer pauzeren dan andere wanneer je op Step Over drukt\u003C\u002Fli>\n\u003Cli>Loops die veel vaker itereren dan verwacht (voeg een tijdelijke variabele toe om iteraties te tellen)\u003C\u002Fli>\n\u003Cli>Geneste scriptoproepen (Perform Script) die andere scripts activeren die je helemaal vergeten was\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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 \u003Cstrong>Go to Record\u002FRequest\u002FPage\u003C\u002Fstrong> stap ontbreekt.\u003C\u002Fp>\n\u003Ch2>Stap 3: Gebruik de Data Viewer om specifieke expressies in te stellen\u003C\u002Fh2>\n\u003Cp>Het Watch-tabblad van de Data Viewer laat je berekeningen live evalueren terwijl een script draait. Als je vermoedt dat een bepaald berekeningsveld of \u003Ccode>ExecuteSQL\u003C\u002Fcode> 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.\u003C\u002Fp>\n\u003Ch2>Stap 4: Instrumenteer het script zelf met tijdstempelvariabelen\u003C\u002Fh2>\n\u003Cp>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:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Set Variable [ $start ; Get ( CurrentTimeUTCMilliseconds ) ]\n# ... verdachte trage sectie ...\nSet Variable [ $elapsed ; Get ( CurrentTimeUTCMilliseconds ) - $start ]\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Log \u003Ccode>$elapsed\u003C\u002Fcode> naar een variabele, een tekstbestand (via Insert File \u002F 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\u002Fstop 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>[[IMAGE:left|een script met tijdstempelpunten die één trage sectie onthullen]]\u003C\u002Fp>\n\u003Ch2>Stap 5: Controleer FileMaker Server-side, niet alleen client-side\u003C\u002Fh2>\n\u003Cp>Als het script draait als een Server Schedule of via Data API\u002FOData, zullen geen van de bovenstaande client-side tools het rechtstreeks vangen. In plaats daarvan:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Controleer het \u003Cstrong>Server Stats log\u003C\u002Fstrong> in FileMaker Server Admin Console op verstreken tijd per scriptplanning\u003C\u002Fli>\n\u003Cli>Schakel het \u003Cstrong>Topcall \u002F slow query\u003C\u002Fstrong> 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\u003C\u002Fli>\n\u003Cli>Controleer de \u003Cstrong>Client Statistics\u003C\u002Fstrong> in Admin Console tijdens de trage bewerking om te zien of het CPU-gebonden, I\u002FO-gebonden, of wachtend op netwerkronde-trips is\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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).\u003C\u002Fp>\n\u003Ch2>Wat zijn de meest voorkomende oorzaken eenmaal je het trage gedeelte hebt gevonden?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Niet-geïndexeerde zoekopdrachten\u003C\u002Fstrong> — 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Loops met een Set Field in plaats van een batch replace\u003C\u002Fstrong> — 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 \u003Ccode>Get(FoundCount)\u003C\u002Fcode> controles.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Onnodige Commit Record stappen in een loop\u003C\u002Fstrong> — elke commit is een ronde-trip naar de server. Commit eenmaal, aan het einde, indien mogelijk.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Portals en niet-opgeslagen berekeningen op layouts\u003C\u002Fstrong> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>ExecuteSQL\u003C\u002Fcode> query's zonder juiste indexering\u003C\u002Fstrong> of uitgevoerd tegen tabellen veel groter dan de ontwikkelaar oorspronkelijk testte.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Gekoppelde scripts die scripts oproepen die scripts oproepen\u003C\u002Fstrong>, elk met zijn eigen overhead, wanneer één geconsolideerd script dezelfde taak met minder heen-en-weer zou doen.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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 \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-improve-the-performance-and-structure-of-a-filemaker-solution\">hoe je de prestaties en structuur van een FileMaker-oplossing kunt verbeteren\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Kan AI helpen trage scripts sneller te vinden?\u003C\u002Fh2>\n\u003Cp>Ja, steeds meer. Claris' eigen AI-assistent, \u003Cstrong>Klai\u003C\u002Fstrong>, 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.\u003C\u002Fp>\n\u003Cp>Layout-gerelateerde traagheid is een apart maar gerelateerd probleem: tools zoals \u003Cstrong>FMBetterForms\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\u003Ch2>Een snelle checklist voor het zoeken naar een traag script\u003C\u002Fh2>\n\u003Col>\n\u003Cli>Time de trage actie met een stopwatch en noteer de exacte stappen die worden ondernomen\u003C\u002Fli>\n\u003Cli>Identificeer welke script(s) während die actie draait (gebruik Script Debugger of een Log-tabel)\u003C\u002Fli>\n\u003Cli>Voeg tijdstempelpunten toe rond elk hoofdblok van het script\u003C\u002Fli>\n\u003Cli>Voer het uit tegen realistische (niet test) gegevensvolumes\u003C\u002Fli>\n\u003Cli>Controleer of het client-side of server-side is, en test beide van een lokale en externe verbinding\u003C\u002Fli>\n\u003Cli>Kijk naar de gebruikelijke verdachten: niet-opgeslagen berekeningen, loops met per-record commits, niet-geïndexeerde zoekopdrachten, gekoppelde scripts\u003C\u002Fli>\n\u003Cli>Repareer één ding tegelijk en meet opnieuw — verander niet vijf dingen tegelijk en hoop\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>Veelgestelde vragen\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Heeft FileMaker een ingebouwde performance profiler?\u003C\u002Fstrong>\nNiet echt een speciale, maar de Script Debugger, Data Viewer, en Server's Client\u002FStats logs samen dekken het meeste wat een profiler zou geven — je hoeft alleen maar zelf het plaatje in elkaar te zetten.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Waarom draait een script snel voor mij maar traag voor een collega?\u003C\u002Fstrong>\nMeestal netwerklatentie (externe vs lokale verbinding), een veel groter gevonden set aan hun kant, of een privilege set die extra validatieberekeningen dwingt te evalueren.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Moet ik scripts proactief optimaliseren of alleen wanneer gebruikers klagen?\u003C\u002Fstrong>\nEen 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is een traag script altijd een scriptingprobleem?\u003C\u002Fstrong>\nNee. 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901677000,[19,20,21,22,23],"FileMaker performance","script optimization","FileMaker debugging","Claris FileMaker","custom app maintenance","\u002Fapi\u002Fknowledge\u002Fimage\u002F375\u002F?v=4b5c652c792c",false,"",null,{"title":29,"slug":30},"FileMaker en Claris","filemaker-and-claris",{"title":32,"slug":33},"Hoe u de prestaties en structuur van een FileMaker-oplossing kunt verbeteren","how-to-improve-the-performance-and-structure-of-a-filemaker-solution"]