Thanks for posting!
Is this script simple enough for you to post a quick outline here?
Does this occur if you create a similar script in a new database?
Do you have another installation of FileMaker Server that you can test with?
It's a long script with several sub scripts.
This would be a very difficult script to test with a new file. Don't have the equipment for it and it would require running the same script for 1000's of times to get one possible error.
This is a point of sale type production environment.
I am now slowly, carefully updating the script to use what I consider to be a better scripting design, but the script should work as written. Keep in mind that we've been using it for several years and if there was a scripting error, it would fail far more frequently.
My current "long shot theory" is that a loop in the script fails if it runs at just the wrong instant in time and thus runs afoul of the scheduled back up.
It loops through the records in a portal and uses: $Row > Count ( PortalTable::ForeignKey ) to exit the loop.
Since the system "looks" like its trapped in an infinite loop, I'm working up a version of the script that can loop throught the portal records on a separate layout by using Go To Related Records to produce a found set of them on that layout.
Among other changes, this will allow me to to use Go To Record/Request/Page [next ; exit after last ] to terminate the loop.
This is also an installation of FMS 10 that goes "deaf" from time to time, but I've checked the admin console to make sure that I don't have things "stuck" on a scheduled back up and it's currently working just fine.
Once I "go live" with the new script, it'll take a while before I can decide if it made any difference or not as this may only occur once in a 1000 invoices created and printed on the system.
Update: The changes I made to this script, as I expected, did not affect this issue.
The back up schedule, BTW, takes less than a minute to complete.
I'm going to question my users further on whether this "hang" is permanent or whether control eventially returns to the user if they wait long enough.
I'm also going to give them a button to click that logs each incident so that I can more carefully compare when this happens to the back up schedule to see if I can spot any patterns.
Further update, users report that they eventually regain control of the system if they wait long enough--which rules out an infinite loop.
This is a point of sale environment with customers waiting their turn in line. Even a delay of 5 minutes is intolerable here.
May have to disable hourly backups schedule for the afternoon to see if this problem then goes away or continues. Hate to give up the added data security of those extra back ups.
Update, we've crossed our fingers and disabled the hourly backups. For about 8 hours of using the database. so far, not one "hang" has occurred--which appears to confirm that the hourly backups are somehow the cause of this issue.
TSBear, I can send you a clone of this file and let you know which script is being performed when this happens if you'd like to take a closer look at it. Just let me know to which email address to send it.
Check your Inbox at the top of this page for instructions where to send the file.