6 Replies Latest reply on Jun 17, 2011 1:23 PM by TSGal

    Server Scheduled Backups are "hanging" client side scripts

    philmodjunk

      Summary

      Server Scheduled Backups are "hanging" client side scripts

      Product

      FileMaker Server

      Version

      10 and FileMaker Pro 10v3

      Operating system version

      Windows Server 2008, SP2, 64 bit, Windows XP sp3

      Description of the issue

      There's a script that our data entry folks perform thousands of times a day by clicking a button. This script creates some new records for auditing purposes and then flags an invoice record as ready for our cashiers to print.

      On occasion, the screen turns white, an hour glass is displayed and the script never halts. Task Manager reveals that the CPU is running at 90+%. THe appears to have been paused, (a layout change with no screen refresh likely causes the blank screen look), but the script is not able to resume.

      This happens when the data-entry clerk happens to click on the button at the same instance that a scheduled back up is starting up on the server. When we reschedule the back up to take place on the half hour, the problem reappears on the half hour--which is why we know that the backup is a factor here.

      The scheduled backup does not verify and originally took place on the hour every hour during normal business hours. We've since recheduled to every two hours on the half hour to reduce the odds that this will happen, but it still happens. It's as though Server never reports back to the client that the back up is complete so that the interrupted script can resume.

      Workaround

      Force Quite FileMaker on the client machine and re-open the database.

        • 1. Re: Server Scheduled Backups are "hanging" client side scripts

          PhilModJunk:

          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?

          TSBear
          FileMaker, Inc. 

          • 2. Re: Server Scheduled Backups are "hanging" client side scripts
            philmodjunk

            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.

            • 3. Re: Server Scheduled Backups are "hanging" client side scripts
              philmodjunk

              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.

              • 4. Re: Server Scheduled Backups are "hanging" client side scripts
                philmodjunk

                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.

                • 5. Re: Server Scheduled Backups are "hanging" client side scripts
                  philmodjunk

                  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.

                  • 6. Re: Server Scheduled Backups are "hanging" client side scripts
                    TSGal

                    PhilModJunk:

                    Check your Inbox at the top of this page for instructions where to send the file.

                    TSGal
                    FileMaker, Inc.