Have you tried putting the file on another computer? If the script gives false find results then, it means you may have a corrupted file. If the script works properly, it may mean that something else is happening on the robot computer at the same time the script is running and is conflicting with FileMaker.
Yes this is a served file and I do think that it is an issue with the PC and client. When it started misbehaving earlier last week I ran the same script from my PC and it behaved as expected, so I then re-launched the client on the Robot and it started to run correctly again until a few days later. The processes run at the same time every day and the event logs are not showing anything happening around the same time that might be a source of conflict. This is a dedicated desktop situated in the serer room so I know I am the only one accessing this box. I have never seen fllemaker return false results before and the last few weeks have shown the only fix is to exit and re-open the app.
The machine has 8GB of Ram and has a 64-bit operating system so I dont think it is a memory issue.
Many thanks for your reply,
What happens if do the Find outside of the script?
After the script debugger started flashing wildly I got a bit concerned and immediately exited the app, I will need to wait a few days until it starts to error again to try this and will let you know. One of the finds it is doing (where it was reporting records had been found where there were none to be found) is a simple check for duplicates e.g enter find, set ID field to "!", perform find and send me an e-mail if it finds some. There is no process to clear these out so the fact that when I ran it locally on my pc this mornning and it found the expected zero in incongruent.
The other one where it was returning 0 when it should have been finding records is a bit more complicated but nothing outrageous. As the robot runs its processes I quite often script it to send me an e-mail to tell me how many it found or how many emails it sent just so I can monitor it. It is very friendly and probably emails me a dozen or more emails each day/night.
Last week when it was not behaving as expected I ran the script on my machine and it worked fine, so then I logged into the robot and nothing looked amiss but I did a re-launch and the next night it did as expected. This time after I logged in I ran the script to confirm it was finding 0, I then tried it with the script-debugger but exited out before completion due to the onscreen mayhem, then I did the re-launch, then I ran the script again on the robot and it found 336 records and sent the emails. Nothing had changed except I had exited out and back into the app.
One thing I will try to dig into is the impact of the servers disconnecting a client. The robot calls on files that are spread accorss 3 servers via one processing file that calls the others. Perhaps the issue is to do with the amount of time that has lapsed since I first logged that file on. I know that file is still available as I can see it open on the robot but I wonder if the others are being timed out. I am not sure how this works, I thought that it would try to open these files as it went to run the scripts in them and they have the same username and pw as the open file (and encrytption password saved). I have only ever had to open the robot file in the past. Very odd that it runs for a few days as expected and then starts returning the bad find results?
I will revist all the files it calls and make sure "Disconnect user from server while idle" is not checked for that priv set but we have never had any issues with this previously and these scripts have been running realiably on our old robot for 4 years but it may be to do with a behaviour change we have not picked up in the upgrade?
I will also put some more error capturing into the scripts immediately after the finds, at the moment I am really just testing the found count but I will capture the last error at a few points as well in a variable and add to the email. At this stage I don't think it is the scripts but the environment but maybe they will capture something I am missing.
Sounds like you should be using FileMaker Server. You didn't say you were, so I'm assuming you are not.
Do I assume correctly from "It is running Filemaker Pro Advanced 13.3" that you are currently running WITHOUT FM Server? (I note that Allen has wondered the same thing.) If so, you are running just peer to peer. In that configuration whichever user opens the DB first in a given session becomes the "host" for that session—even if the DB itself resides on another machine. This is not a good or desirable situation. Could this be the reason you are getting very insconsistent performance?
Try resetting the indexes on the fields in question
http://www.filemaker.com/help/html/recover.39.12.html ( first item )
note: even if served "peer to peer", there is no reason for a "find" to fail
and just out of curiosity, run Recover, and check the resulting Log for any items "changed"
> is a simple check for duplicates
Yes we have been using a robot ( a dedicated pc with fmpa running ) for a number of years. We use the events plugin to schedule the scripts to run at set times. The robot runs a large number of processes everyday and the reasons we have not moved the 40-50 tasks off this box to server is a. because we are attaching pdfs to emails that we are creating from the db with unique barcodes on them (around 80,000 a year) and b. because we are importing data nightly from a mapped network drive.
I realise there are work arounds for creating the pdfs on the server and that we could xcopy the csv’s each night to one of the two locations that filemaker now supports importing from. However I am not keen on introducing any new points of possible failure.
I would be in a much better place if the script debugger had of behaved this morning, the way it was flashing on the screen does suggest the app was not well. I will have to wait now a few days until the problem presents again. What I am most nervous about is the fact I would lose my job if it returns an erroneous found set and sends emails to students with the wrong communications. I have never had to worry about this before as for a as long as I have been using filemaker I have never seen it do this before (there has always been a logical explanation and it has been to do with my find requests!) There will of course be an explanation, I am just yet to identify it.
I will report back anything I find whilst trouble shooting which may include looking at the anti-virus etc. I have not seen any of this behaviour in my own client so I feel like the issue is something to do with that box.
Many thanks for your responses today.
Since 0 Found is normal, perhaps you could pause the script for your review, when records are found, before any emails are sent, until this is resolved
> What I am most nervous about is the fact I would lose my job if it returns an erroneous found set and sends emails to students with the wrong communications. I have never had to worry about this before as for a as long as I have been using filemaker
Despite the fact that you have been running this robot without issue for many years, now you are faced with a problem.
I have a robot running for one of my customers that twice per day sends new orders across to their warehouse (about 50 miles away).
This is still running in FMP11, so I haven’t come across your issues, but may I suggest that, like me, you quit FileMaker on your robot at least once per day. This will erase any problems that might build up over a period of time, which is obviously being caused by a memory leak within FileMaker.
I don’t remember which platform you are using, but it is easy to find a small timer utility that can start up FileMaker at the same time each day. The FileMaker script that runs the last procedure of the day can have ‘Quit Application’ added, so FileMaker is closed down. These open and close times could be as close as 30 mins, but I would allow for at least an hour closed down time (to cope with Daylight saving time changes).
In this way, I believe that your FileMaker Robot will continue to provide reliable service, despite the issues that you have been seeing recently.
Best wishes- Alan Stirling, London UK.
You search on calculated field (unstored) ?
Look at this bug report,
worakaround is same : put a let to a relationship to another table which is in another file
Yikes ! Thanks for posting that
but, in this case, they should have seen the problem also in FileMaker 11
> Look at this bug report
worth a try anyway, and also, you know, people… :-)