1 of 1 people found this helpful
check the event log for what FMS has to say about any errors in the scripts.
On the schedule you can set a time-out and abort. The abort should take care of stopping the script at that time.
If it doesn't, nothing you can do about it in FMS11 short of stopping the database engine.
In FMS12 you can restart the script engine separately without affecting the database engine.
The real fix however is in error trapping and handling of what the script does.
Thanks for the reply. You are right that the real fix is in error trapping. I did a lot of work today to overcome the 101 and 401 errors because I suspected they might be the cause of the problem and so far, that turns out to be the solution I was looking for.
But I should add that, IMHO, this kind of work should not be necessary. When a loop correctly ends with a Got to Next Record, Exit after Last script step, that should NOT produce a scripting error message, especially if Error capture is turned on. What I found as a workaround is to use the Omit step and Exit the Loop on whatever condition fits the circumstances - but I find this distasteful because it just adds unnecessary complexity and more time consuming work to what is otherwise a very straightforward way of allowing scripts to process records in a loop. The main problem is getting the desired action to perform upon the last record in a found set without exiting the loop before that action has occured. It really requires a lot of backward thinking compared to the straightforward scripting of a loop.
I am even more opinionated about the 401 errors. Very often, No Records Found is the intended result in a script that branches in different directions based on the results of a scripted FIND command. On my server, I am running a recurring script that checks for new records or changed records, and most of the time, no further action is needed when no records are found. My workaround for this today was to create a single special record that is always found, so that the found set is either 1 or more. That way, a found set of 1 can be scripted to do what a found set of zero did before, after omitting the special record. To make sure that users don't accidentally delete this record, I defined the privilege sets so that this particular record cannot be deleted, no matter what. That required making new privilege sets for any users who use FM's default privilege sets for read-only, full access, etc.
We should not have to perform all these workarounds to trap errors that are not errors. I know from another thread that FileMaker says there are no errors that are not errors. Rather than argue about those semantics, I would suggest that they call these something else, like EXTRAORDINARY ANTICIPATED SCRIPT INTERCEPTED EXCEPTION RESULTS. Maybe someone can think of a better acronym than EASIER, but that's my best suggestion.
If the event log does not show that script is running, but it says "running" in the console, then it is almost certainly not running. In FM Server 11, I find that the admin console needs kicking to correctly display the status. You can restart it on the command line without effecting anything else. I also find that if schedules don't show the correct times that they have run or email notifications stop, restarting the console will fix these issues as well.
> fmsadmin restart adminserver
If after doing this, it still says "Running", then a full stop/start of the FM server is needed. I have only seen this on the rare occasion.
In my opinion, the extra work you did in error trapping is a bit overkill. The looping script trapping is fine, but the workaround for avoiding 401 not found errors is not needed. I have not seen this error be an issue in server-side scripts. Wim has a ton of experience in this area, so he may know different. For looping through a found set, try this simple formula. It will process the last record and then exit without error.
Set Variable $foundCount = Get (FoundCount)
Set Variable $i = 1
Exit Loop If $i = $foundCount
Set $i = $i + 1
Go to Record Next
Thanks, Doug. That simple formula is a good one. The setting of the incremented variable never occurred to me. That's just what I needed.
BTW, I tried your idea for kick-starting the admin server, but I get an error that says "Windows cannot find fmsadmin". DId I misunderstand how to do this?
I know we all have our favorite way to accomplish the same thing, but here is how I do loops to avoid the log file error:
Exit Loop If ( Get ( FoundCount ) = Get ( RecordNumber ) )
Forgot to mention that when using the command line, you need to change directory to be the folder where the FM server executable is located. Otherwise, you would need to modify the Window's PATH environment variable to include the FM server executable folder. If you do that, then the command "fmsadmin" will resolve no matter what directory your command prompt is currently in.
Yep - many ways to get to the same end result in FileMaker.
I changed my "standard" back a bit ago after watching some webinar's on tuning code for speed and reading some of Honza's articles about performance optimizing. Both of these advocated minimizing the number of times FileMaker had to evaluate things (for instance, "Get" functions) among many other tips. Thus, the idea of only calling Get(FoundCount) once and so forth. It adds a couple of lines of code over your method, but they claim that this is more than offset by the overhead of the evaluation's.
Having said this, I am not one to go measure this stuff in my actual solutions. I know that others have done this though, so I trust their research/testing enough to adopt some of these techniques and try to think about optimization as much as I can.