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).
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
Stat40&41-> 29: 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.
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.
- To rebuild the index of a single field, open Manage | Database | Fields and double click the field definition
- Use either the storage tab or the storage options button to turn off indexing.
- 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:
- With the file closed, select Recover from the File Menu.
- Select "Use advanced Options"
- Select only: "Copy File Blocks as-is" and "Rebuild Field Indexes Now".
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.
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.)
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.