Not a Server expert, myself—others will chime in shortly, I'm sure—but to get the ball rolling…
What eveidence, if I may ask, leads to your conclusion that the script continued execution? If it is the 800K new records, is it possible that those were created in the looping process that compelled your user to force quit in the first place (i.e., created by a "stuck" loop before he quit)? Depending on the complexity of the script and a few other variables, it wouldn't take long for a run-away script (i.e., without an expected exit condition being met) to create 800K records. FileMaker's run-time execution of scripts can be pretty fast.
Just a thought.
Hoping you get to the bottom of it.
P.S. Although you are probably already working on restoring from a backup, if not, you should strongly consider doing so, as the force-quit itself may have introduced file damage (as your observations already suggest).
Thanks Mark! The evidence I have is just the record creation timestamps, which go on all night and into well into the next day - stopping, mysteriously, at 4:36 am.
My last backup was yesterday 1pm, and I would rather go back to it, but the users rebelled and I'm now hosting the compressed copy, which appears to be workign normally. But I really need to know if I can keep this from happening again - it's really scary.
Just on a wild chance ... does that server box have a program named SuperDuper ?
I ask because when I saw your mention of 4:36AM I was reminded of a mystery I had with a client (who had users in multiple timezones) wherein clients got disconnected at 4:36AM server time.
Turned out that the admin IT guys used SuperDuper backup system which had that as the default time. Crazy, I know.
It was 6:30, he was tired, so he force-quit Filemaker and went home
Based in reading between the lines of the above, my guess is that FM did not quit at all. I have occasionally had an OS level command such as shut down being cancelled by a running application (not FM) because of some process that was in progress, so I assume it is possible that FM cancelled the force quit because the script was running, and that your user, being tired and running late, did not wait around to make sure FM had actually quit but rather just assumed it had. Force quit is fairly "forceful" though, and for what it's worth I just ran a test on a little test file with a looping script running and it seems to stop dead when force quit is ordered.
If the script your client called started a server-side script, it is quite possible that his force-quit of the Pro client had no effect on what FM Server was already churning through.
Also curious about the purpose of a script which can produce duplicates of 800K records without some type of testing in the loop to control the size of the found set on which it is allowed to act. Seems like some tests within the loop for found count and context could help avoid a runaway process in the future.