6 Replies Latest reply on Apr 13, 2011 4:01 PM by

    Server Side Script Ignoring Perform Finds?


      Server Side Script Ignoring Perform Finds?


      FileMaker Server


      Operating system version

      Windows Server 2008 R2 64bit

      Description of the issue

      - running a server side script during the day every half hour
      - 100K records.
      - Finds records and updates the status of found set
      - during busy times server side script doesn't seem to wait until a found set is return
      - Current users is about 60 that are connected with many request coming from PHP with finds and adding new records
      - no errors are report during script It will always returns an error code of 0.

      Steps to reproduce the problem

      - Perform finds and do a replace field contents.  The script has about 5 different Perform Find(Restore) steps.
      - Currently I have to put a show all records before every find and then make sure that it won't change any records unless it found a set less than 1,000.
      - It will always perform the show all command but the perform find is not done at random times.  This seems to only happened during the middle of the day when the load seems to be heavy.

      Expected result

      To perform the command it was asked to do or at least give an error message rather then skipping over it.

      Actual result

      Ignores the Find or doesn't wait for it to finish - unsure of which.  Every time we run this on the client it seems to perform just fine.

      Configuration information

      FMS Advanced


      Show All Records
      Perform Find
      If get(lasterror) = 0 and get(foundcount) < $_limit then proceed.  This is the only way we have been able to have any confidence that the data won't get messed up.

        • 1. Re: Server Side Script Ignoring Perform Finds?

          Have you considerered the possibility that your find is working correctly but that Replace Field contents is not?

          If one of your users is editing a record that your script has found and is now using Replace Field Contents to update, that record will not be updated and thus, even if your scripted find is working correctly, you may find discrepancies in your results. 

          This does not appear to be a script that can run safely at a time when other users may be editing the same record(s).

          • 2. Re: Server Side Script Ignoring Perform Finds?

            I have an that is email sent to me with the results of each find which tells me what the foundset count was.  When it fails it will have for example  Stat29->48: 99748

            Step1:   99748
            Layout: _Cust
            Stat46->29:   8
            Stat46->40:   0
            Stat40&41-> 29:   1
            Stat40->41:   99748
            Stat29->48:   99749
            Stat43->44:   1

            This happens even before a replace field command is ever called.  If someone is editing a record - the record is ignored and updated the next time.

            • 3. Re: Server Side Script Ignoring Perform Finds?

              If you run this same script as a client, does it work reliably? (That tests to see if the schedule is a factor here or not.)

              You haven't described how your script performs the find or what criteria is specified so we can't see if there's any issues there that might be a factor or not.

              Sometimes, finds go wonky due to a field having a corrupted index.

              1. To rebuild the index of a single field, open Manage | Database | Fields and double click the field definition
              2. Use either the storage tab or the storage options button to turn off indexing.
              3. Exit Manage | Database, then return and turn indexing back on.


              You can also rebuild all your file's indexes by importing all the data into an empty copy (clone) of your file.

              If you have FileMaker 11, you can use Advanced Recovery options to rebuild your file's indexes:

              1. With the file closed, select Recover from the File Menu.
              2. Select "Use advanced Options"
              3. Select only: "Copy File Blocks as-is" and "Rebuild Field Indexes Now".

              • 4. Re: Server Side Script Ignoring Perform Finds?

                Everytime we have run this on the client side it seems to perform as expected.   Granted we have not run this on the routine of every half hour.  As far as the indexes go we pulled the data in a cloned copy about a month ago which would have rebuilt the indexes.  I am game to rebuild the indexes if I need.  The find are a perform find(restore).  We tried it both both way to enter find mode, set the criteria and then perform the find vs. perform find(restore) and it made no difference.

                • 5. Re: Server Side Script Ignoring Perform Finds?

                  What criteria are you specifiying in the find?

                  The only significant difference that I am aware of in Server Side scripts that might affect this find is that server side scripts execute from a "host" perspective instead from a "client" perspective. That makes very little difference except that if your script modifies a global field value, the value change persists. Can't imagine how that would affect your script's behavior here...

                  And I have a server side script runs every night and that performs a find that has never had a problem like this...

                  Have you tried checking the file for possible corruption by running a recover on a recent back up copy of the file? (You can move the copy to a workstation and set it to recover the file while you break for lunch or even leave for the night and check back later to see if it's done.)

                  • 6. Re: Server Side Script Ignoring Perform Finds?

                    Ran the recover again just to make sure and no problems detected.  The finds are very straight forward.  No global fields are involved.  Finds involve numeric, date and text.  90% of the time it performs as designed...Night time seems find with other script.  Only during peak times seems to exhibit the issue.