Internal table overflow generally means a script is too complex. It’s often caused by scripts that are too long, but it can also be caused by things like too much nesting or too much recursion.
I’m pretty sure FileMaker uses a single instance of AppleScript to run all scripts, so it’s possible your script is just tipping things over the edge. Probably the best suggestion is for users to quit and relaunch FileMaker, and see if it goes away.
Now I see, with scripting addition I was wrong. But…
Logically, if you send this event repeatedly, without waiting for a response from the Mail ArchiverX, and Mail ArchiverX does not have time to process them, then this events accumulate in the queue and overflows the memory. You can add the necessary delay immediate after the event sending to solve this problem
tell application id "com.mothsoftware.mailarchiverx"
ignoring application responses
«event M" & Right ("0000000" & Mail::RecID; 7 ) & "»
Thanks, that makes sense. Doing the async processing is a bit annoying. When my app gets the AppleEvent the next email is processed. I don’t really like the idea of a delay because speed is important. But I’ll try a smaller delay.
I’d rather lose some time with a proper delay than attempting close Filemaker, restart the machine, perform a checkup with DiskUitility, rebuilt the directory with DiskWarrior and get the very same error at more or less 4000 mails.
In any case, when the mails to archive are several, nothing else can be done with the Mac. So minutes, or half hours, or even hour more will be welcome if the FMP database would collect whatever is needed soundly
Model: MacBook PRO
Browser: Safari 537.36
Operating System: macOS 10.14